[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #20 from kargls at comcast dot net ---
(In reply to Jürgen Reuter from comment #19)
> Created attachment 58476 [details]
> First independent reproducer

It appears to be a striding issue.  The loops at formf.f:507 is

   DO 206 I=1,4
  DO 206 J=1,4
 ! print *, "hadcur(i) before= ", hadcur(i)
 HADCUR(I)=
 $HADCUR(I)+CMPLX(FIX*COEF1)*FORM1*AA(I,J) !*(PP(K,J)-PP(4,J))
 ! print *, "hadcur(i) after = ", hadcur(i)
 206   CONTINUE
C --- end of the non omega current (3 possibilities)
 201   CONTINUE

For a Fortran programmer, these loops are backwards.  If you do 

   DO 206 J=1,4
  DO 206 I=1,4
 ! print *, "hadcur(i) before= ", hadcur(i)
 HADCUR(I)=
 $HADCUR(I)+CMPLX(FIX*COEF1)*FORM1*AA(I,J) !*(PP(K,J)-PP(4,J))
 ! print *, "hadcur(i) after = ", hadcur(i)
 206   CONTINUE
C --- end of the non omega current (3 possibilities)
 201   CONTINUE

the code compiles and executes after fixing the same issue near line 599.

[Bug tree-optimization/114814] Reduction sum of comparison should be better

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

--- Comment #3 from Feng Xue  ---
The pattern to match the code belongs to a generic dot-product category, we
could consider mapping it to native dot-product instruction with a constant "1"
operand.

moviv29.16b, 0x1
.L4:
ldr q31, [x1], 16
cmeqv31.16b, v28.16b, v31.16b
and v31.16b, v29.16b, v31.16b
udotv30.4s, v31.16b, v29.16b
cmp x5, x1
bne .L4
addvs31, v30.4s
fmovw1, s31

And if value accumulation does not require widening, as in this case, then
REDUC_PLUS finds its usage, which could be seen as a special instance of
dot-product instruction. But here is one point to note: we should think this
kind of REDUC_PLUS touches whole vector register, modifying the 1st element and
clearing the rest part. Anyway, it would become an addv.

For SVE, since element count is variant, element type may not hold accumulation
result, only dot-product could be used.

Moreover, it is possible to extend the means to handle conditional accumulation
as:

   for (i) {
 if (cond)
   sum += a;   // => sum += cond * a;
   }

[Bug middle-end/106870] ctrl_altering flag is not set correctly

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
It might be useful to add the verifier and test it out again.

[Bug c++/115567] Internal Compiler Error: Segmentation Fault during build

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

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

--- Comment #2 from Xi Ruoyao  ---
*** Bug 115569 has been marked as a duplicate of this bug. ***

[Bug c++/115569] Internal Compiler Error: Segmentation Fault during build

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #1 from Xi Ruoyao  ---
.

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

[Bug rtl-optimization/115573] ICE: verify_flow_info failed with no_reorder attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |rtl-optimization

--- Comment #1 from Andrew Pinski  ---
I suspect this is invalid code; it is definitely undefined.

cprop is trying to turn the computed goto into a regular goto but it is a
non-local goto which it is not valid thing for a computed goto ...

[Bug c/115573] New: ICE: verify_flow_info failed with no_reorder attribute

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

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

Bug ID: 115573
   Summary: ICE: verify_flow_info failed with no_reorder attribute
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

ICE on trunk.
Compiler Explorer: https://godbolt.org/z/8sbP3Ydh6

***
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 version:
Using built-in specs.
COLLECT_GCC=/root/gcc_set/trunk-48a320a/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/trunk-48a320a/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/trunk-48a320a
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak --enable-coverage
--disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240426 (experimental) (GCC) 

***
Program:
$ cat mutant.c
int a;
__attribute__((no_reorder)) int b() {
  __label__ d, e;
  void f(int c) { goto *c ? & : & }
d:
  f(a);
e:
}

***
Command Lines:
$ gcc -O2 mutant.c
mutant.c: In function ‘f’:
mutant.c:4:40: error: basic block 2 edge lists are corrupted
4 |   void f(int c) { goto *c ? & : & }
  |^
during RTL pass: cprop
mutant.c:4:40: internal compiler error: verify_flow_info failed
0x117ca2f verify_flow_info()
../../gcc/gcc/cfghooks.cc:287
0x116b814 checking_verify_flow_info()
../../gcc/gcc/cfghooks.h:214
0x11a913e commit_edge_insertions()
../../gcc/gcc/cfgrtl.cc:2155
0x45abf2f bypass_conditional_jumps
../../gcc/gcc/cprop.cc:1744
0x45ac80c one_cprop_pass
../../gcc/gcc/cprop.cc:1895
0x45acadd execute_rtl_cprop
../../gcc/gcc/cprop.cc:1940
0x45accf0 execute
../../gcc/gcc/cprop.cc:1980
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/100030] ICE: in dependent_type_p, at cp/pt.c:26757

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

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

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

[Bug c++/100031] ICE: in dependent_type_p, at cp/pt.c:26757

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Really the same as PR 100030, sizeof and alignas are handled very similar here.

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

[Bug c++/115572] internal compiler error: in dependent_type_p, at cp/pt.cc:28020

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

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

--- Comment #1 from Anonymous  ---
***
The compiler produces an internal error in lookup_template_class when compiling
the provided code with the specified options. 
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
***
# g++ -v
Using built-in specs.
COLLECT_GCC=g++
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 source_code_1.cpp

template 
auto f(Ts...) {
  [] { enum class e : Ts {}; };
}

int main() {
  f(0, true);
}


***
Command Lines:
# g++ source_code_1.cpp  -std=c++2a -Wall -Wextra -pedantic
-fsanitize=undefined -fsanitize=address -O2 -c -o source_code_1.o
source_code_1.cpp: In instantiation of ‘auto f(Ts ...) [with Ts = {int,
bool}]’:
source_code_1.cpp:7:4:   required from here
7 |   f(0, true);
  |   ~^
source_code_1.cpp:3:19: internal compiler error: in dependent_type_p, at
cp/pt.cc:28020
3 |   [] { enum class e : Ts {}; };
  |   ^
0x825d35 dependent_type_p(tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:28020
0xb55fd3 start_enum(tree_node*, tree_node*, tree_node*, tree_node*, bool,
bool*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/decl.cc:17113
0xcde80b lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:10268
0xcd2cd0 tsubst(tree_node*, tree_node*, int, tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:16265
0xccf2d4 tsubst_decl
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:15435
0xcc77e4 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18541
0xcc6106 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18410
0xcc6106 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18424
0xcc6bee tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18797
0xce1718 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18410
0xce1718 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:19850
0xcbe1a0 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:21757
0xcc4837 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:19482
0xcc55cc tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18442
0xcc6106 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18410
0xcc6106 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18424
0xcc6bee tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18797
0xce0b52 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18410
0xce0b52 instantiate_body
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:27107
0xcc4425 instantiate_decl(tree_node*, bool, bool)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:27392
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/7aPr9fWxn

***

[Bug c++/115572] New: internal compiler error: in dependent_type_p, at cp/pt.cc:28020

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

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

Bug ID: 115572
   Summary: internal compiler error: in dependent_type_p, at
cp/pt.cc:28020
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---
Target: x86_64

[Bug target/115355] [12/13/14/15 Regression] vectorization exposes wrong code on P9 LE starting from r12-4496

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:52c112800d9f44457c4832309a48c00945811313

commit r15-1504-g52c112800d9f44457c4832309a48c00945811313
Author: Kewen Lin 
Date:   Thu Jun 20 20:23:56 2024 -0500

rs6000: Fix wrong RTL patterns for vector merge high/low word on LE

Commit r12-4496 changes some define_expands and define_insns
for vector merge high/low word, which are altivec_vmrg[hl]w,
vsx_xxmrg[hl]w_.  These defines are mainly for
built-in function vec_merge{h,l}, __builtin_vsx_xxmrghw,
__builtin_vsx_xxmrghw_4si and some internal gen function
needs.  These functions should consider endianness, taking
vec_mergeh as example, as PVIPR defines, vec_mergeh "Merges
the first halves (in element order) of two vectors", it does
note it's in element order.  So it's mapped into vmrghw on
BE while vmrglw on LE respectively.  Although the mapped
insns are different, as the discussion in PR106069, the RTL
pattern should be still the same, it is conformed before
commit r12-4496, define_expand altivec_vmrghw got expanded
into:

  (vec_select:VSX_W
 (vec_concat:
(match_operand:VSX_W 1 "register_operand" "wa,v")
(match_operand:VSX_W 2 "register_operand" "wa,v"))
(parallel [(const_int 0) (const_int 4)
   (const_int 1) (const_int 5)])))]

on both BE and LE then.  But commit r12-4496 changed it to
expand into:

  (vec_select:VSX_W
 (vec_concat:
(match_operand:VSX_W 1 "register_operand" "wa,v")
(match_operand:VSX_W 2 "register_operand" "wa,v"))
(parallel [(const_int 0) (const_int 4)
   (const_int 1) (const_int 5)])))]

on BE, and

  (vec_select:VSX_W
 (vec_concat:
(match_operand:VSX_W 1 "register_operand" "wa,v")
(match_operand:VSX_W 2 "register_operand" "wa,v"))
(parallel [(const_int 2) (const_int 6)
   (const_int 3) (const_int 7)])))]

on LE, although the mapped insn are still vmrghw on BE and
vmrglw on LE, the associated RTL pattern is completely
wrong and inconsistent with the mapped insn.  If optimization
passes leave this pattern alone, even if its pattern doesn't
represent its mapped insn, it's still fine, that's why simple
testing on bif doesn't expose this issue.  But once some
optimization pass such as combine does some changes basing
on this wrong pattern, because the pattern doesn't match the
semantics that the expanded insn is intended to represent,
it would cause the unexpected result.

So this patch is to fix the wrong RTL pattern, ensure the
associated RTL patterns become the same as before which can
have the same semantic as their mapped insns.  With the
proposed patch, the expanders like altivec_vmrghw expands
into altivec_vmrghb_direct_be or altivec_vmrglb_direct_le
depending on endianness, "direct" can easily show which
insn would be generated, _be and _le are mainly for the
different RTL patterns as endianness.

Co-authored-by: Xionghu Luo 

PR target/106069
PR target/115355

gcc/ChangeLog:

* config/rs6000/altivec.md (altivec_vmrghw_direct_):
Rename
to ...
(altivec_vmrghw_direct__be): ... this.  Add the
condition
BYTES_BIG_ENDIAN.
(altivec_vmrghw_direct__le): New define_insn.
(altivec_vmrglw_direct_): Rename to ...
(altivec_vmrglw_direct__be): ... this.  Add the
condition
BYTES_BIG_ENDIAN.
(altivec_vmrglw_direct__le): New define_insn.
(altivec_vmrghw): Adjust by calling
gen_altivec_vmrghw_direct_v4si_be
for BE and gen_altivec_vmrglw_direct_v4si_le for LE.
(altivec_vmrglw): Adjust by calling
gen_altivec_vmrglw_direct_v4si_be
for BE and gen_altivec_vmrghw_direct_v4si_le for LE.
(vec_widen_umult_hi_v8hi): Adjust the call to
gen_altivec_vmrghw_direct_v4si by gen_altivec_vmrghw for BE
and by gen_altivec_vmrglw for LE.
(vec_widen_smult_hi_v8hi): Likewise.
(vec_widen_umult_lo_v8hi): Adjust the call to
gen_altivec_vmrglw_direct_v4si by gen_altivec_vmrglw for BE
and by gen_altivec_vmrghw for LE
(vec_widen_smult_lo_v8hi): Likewise.
* config/rs6000/rs6000.cc (altivec_expand_vec_perm_const): Replace
CODE_FOR_altivec_vmrghw_direct_v4si by
CODE_FOR_altivec_vmrghw_direct_v4si_be for BE and
CODE_FOR_altivec_vmrghw_direct_v4si_le for LE.  And replace
CODE_FOR_altivec_vmrglw_direct_v4si by
CODE_FOR_altivec_vmrglw_direct_v4si_be for BE and
CODE_FOR_altivec_vmrglw_direct_v4si_le for LE.

[Bug target/106069] [12/13/14/15 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #40 from GCC Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:52c112800d9f44457c4832309a48c00945811313

commit r15-1504-g52c112800d9f44457c4832309a48c00945811313
Author: Kewen Lin 
Date:   Thu Jun 20 20:23:56 2024 -0500

rs6000: Fix wrong RTL patterns for vector merge high/low word on LE

Commit r12-4496 changes some define_expands and define_insns
for vector merge high/low word, which are altivec_vmrg[hl]w,
vsx_xxmrg[hl]w_.  These defines are mainly for
built-in function vec_merge{h,l}, __builtin_vsx_xxmrghw,
__builtin_vsx_xxmrghw_4si and some internal gen function
needs.  These functions should consider endianness, taking
vec_mergeh as example, as PVIPR defines, vec_mergeh "Merges
the first halves (in element order) of two vectors", it does
note it's in element order.  So it's mapped into vmrghw on
BE while vmrglw on LE respectively.  Although the mapped
insns are different, as the discussion in PR106069, the RTL
pattern should be still the same, it is conformed before
commit r12-4496, define_expand altivec_vmrghw got expanded
into:

  (vec_select:VSX_W
 (vec_concat:
(match_operand:VSX_W 1 "register_operand" "wa,v")
(match_operand:VSX_W 2 "register_operand" "wa,v"))
(parallel [(const_int 0) (const_int 4)
   (const_int 1) (const_int 5)])))]

on both BE and LE then.  But commit r12-4496 changed it to
expand into:

  (vec_select:VSX_W
 (vec_concat:
(match_operand:VSX_W 1 "register_operand" "wa,v")
(match_operand:VSX_W 2 "register_operand" "wa,v"))
(parallel [(const_int 0) (const_int 4)
   (const_int 1) (const_int 5)])))]

on BE, and

  (vec_select:VSX_W
 (vec_concat:
(match_operand:VSX_W 1 "register_operand" "wa,v")
(match_operand:VSX_W 2 "register_operand" "wa,v"))
(parallel [(const_int 2) (const_int 6)
   (const_int 3) (const_int 7)])))]

on LE, although the mapped insn are still vmrghw on BE and
vmrglw on LE, the associated RTL pattern is completely
wrong and inconsistent with the mapped insn.  If optimization
passes leave this pattern alone, even if its pattern doesn't
represent its mapped insn, it's still fine, that's why simple
testing on bif doesn't expose this issue.  But once some
optimization pass such as combine does some changes basing
on this wrong pattern, because the pattern doesn't match the
semantics that the expanded insn is intended to represent,
it would cause the unexpected result.

So this patch is to fix the wrong RTL pattern, ensure the
associated RTL patterns become the same as before which can
have the same semantic as their mapped insns.  With the
proposed patch, the expanders like altivec_vmrghw expands
into altivec_vmrghb_direct_be or altivec_vmrglb_direct_le
depending on endianness, "direct" can easily show which
insn would be generated, _be and _le are mainly for the
different RTL patterns as endianness.

Co-authored-by: Xionghu Luo 

PR target/106069
PR target/115355

gcc/ChangeLog:

* config/rs6000/altivec.md (altivec_vmrghw_direct_):
Rename
to ...
(altivec_vmrghw_direct__be): ... this.  Add the
condition
BYTES_BIG_ENDIAN.
(altivec_vmrghw_direct__le): New define_insn.
(altivec_vmrglw_direct_): Rename to ...
(altivec_vmrglw_direct__be): ... this.  Add the
condition
BYTES_BIG_ENDIAN.
(altivec_vmrglw_direct__le): New define_insn.
(altivec_vmrghw): Adjust by calling
gen_altivec_vmrghw_direct_v4si_be
for BE and gen_altivec_vmrglw_direct_v4si_le for LE.
(altivec_vmrglw): Adjust by calling
gen_altivec_vmrglw_direct_v4si_be
for BE and gen_altivec_vmrghw_direct_v4si_le for LE.
(vec_widen_umult_hi_v8hi): Adjust the call to
gen_altivec_vmrghw_direct_v4si by gen_altivec_vmrghw for BE
and by gen_altivec_vmrglw for LE.
(vec_widen_smult_hi_v8hi): Likewise.
(vec_widen_umult_lo_v8hi): Adjust the call to
gen_altivec_vmrglw_direct_v4si by gen_altivec_vmrglw for BE
and by gen_altivec_vmrghw for LE
(vec_widen_smult_lo_v8hi): Likewise.
* config/rs6000/rs6000.cc (altivec_expand_vec_perm_const): Replace
CODE_FOR_altivec_vmrghw_direct_v4si by
CODE_FOR_altivec_vmrghw_direct_v4si_be for BE and
CODE_FOR_altivec_vmrghw_direct_v4si_le for LE.  And replace
CODE_FOR_altivec_vmrglw_direct_v4si by
CODE_FOR_altivec_vmrglw_direct_v4si_be for BE and
CODE_FOR_altivec_vmrglw_direct_v4si_le for LE.

[Bug tree-optimization/115571] New: `cmp * float` vs `tmp_bool * float` and better vectorization for `cmp * float`

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

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

Bug ID: 115571
   Summary: `cmp * float` vs `tmp_bool * float` and better
vectorization for `cmp * float`
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  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 f(float *c, int *a)
{
  for (int i = 0; i < 1024; i++)
  {
bool t = a[i] == 10;
c[i] = t * c[i];
  }
}

void f1(float *c, int *a)
{
  for (int i = 0; i < 1024; i++)
  {
c[i] = (a[i] == 10) * c[i];
  }
}
```

The second one is vectorized better than the first one at -Ofast due to the
second one being converted into `(a[i] == 10) ? c : 0` in fold before
gimplification.

This was inspired by https://github.com/llvm/llvm-project/pull/96216 .

[Bug middle-end/115570] array subscript 'long unsigned int[0]' is partly outside array bounds of 'unsigned char[4]'

[Curt.Blank at curtronics dot com via Gcc-bugs]

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

--- Comment #4 from Curtis J Blank  ---
Thank you the information.

So I should use unsigned int now on x86_64?

Where can I read more on the rule violations and what would be the proper so do
this?

[Bug middle-end/115570] array subscript 'long unsigned int[0]' is partly outside array bounds of 'unsigned char[4]'

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

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

--- Comment #3 from Andrew Pinski  ---
Note there is also an alignment requirement that you violate with the
assignment and access of the char array too.

[Bug middle-end/115570] array subscript 'long unsigned int[0]' is partly outside array bounds of 'unsigned char[4]'

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

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

--- Comment #2 from Andrew Pinski  ---
Note this code also violates C/C++ aliasing rules but that is a different
issue.

[Bug middle-end/115570] array subscript 'long unsigned int[0]' is partly outside array bounds of 'unsigned char[4]'

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
The warning is correct.
sizeof(long) on x86_64 is 8 rather than 4 that it was on i686.
So when you do this:

unsigned char cValue[4];
unsigned long *value = 0;
value = (unsigned long *)cValue;

*value & 0x

You get undefined behavior because you are reading 8 bytes from a 4 byte array.

[Bug c/115570] New: array subscript 'long unsigned int[0]' is partly outside array bounds of 'unsigned char[4]'

[Curt.Blank at curtronics dot com via Gcc-bugs]

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

Bug ID: 115570
   Summary: array subscript 'long unsigned int[0]' is partly
outside array bounds of 'unsigned char[4]'
   Product: gcc
   Version: 13.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Curt.Blank at curtronics dot com
  Target Milestone: ---

I just ran into a compile error on code that has been just fine for 18 years.
The only reason I'm compiling it is just to be sure on a new computer/Linux
install.

With gcc 4.8.3 I do not get the warnings, with gcc 13.3.0 I get the warnings
shown below the code below. The char string being converted is hex, data
returned from a solar inverter.

And like I said it's been fine and I suspect the program will run fine just
cannot fully test it yet until data collect is moved to this new server.


*--
szCvrtLong
Converts a 4 char string to a long.
*/
unsigned long szCvrtLong(char *Buffer)
{
unsigned char cValue[4];
unsigned long *value = 0;

if (! bSwapEndian) {
cValue[0] = Buffer[aParam4] & 0xff;
cValue[1] = Buffer[aParam3] & 0xff;
cValue[2] = Buffer[aParam2] & 0xff;
cValue[3] = Buffer[aParam1] & 0xff;
} else {
cValue[0] = Buffer[aParam1] & 0xff;
cValue[1] = Buffer[aParam2] & 0xff;
cValue[2] = Buffer[aParam3] & 0xff;
cValue[3] = Buffer[aParam4] & 0xff;
}

value = (unsigned long *)cValue;
if (bVerbose) fprintf(stderr, "szCvrtLong   %12lu
0x%02x%02x%02x%02x\n",*value &
0x,cValue[3],cValue[2],cValue[1],cValue[0]);

return(*value & 0x);
}

---

comm.c: In function 'szCvrtLong.constprop':
comm.c:1906:77: warning: array subscript 'long unsigned int[0]' is partly
outside array bounds of 'unsigned char[4]' [-Warray-bounds=]
 1906 | if (bVerbose) fprintf(stderr, "szCvrtLong   %12lu
0x%02x%02x%02x%02x\n",*value &
0x,cValue[3],cValue[2],cValue[1],cValue[0]);
  |
^~
comm.c:1890:19: note: object 'cValue' of size 4
 1890 | unsigned char cValue[4];
  |   ^~
comm.c:1908:12: warning: array subscript 'long unsigned int[0]' is partly
outside array bounds of 'unsigned char[4]' [-Warray-bounds=]
 1908 | return(*value & 0x);
  |^~
comm.c:1890:19: note: object 'cValue' of size 4
 1890 | unsigned char cValue[4];
  |   ^~

[Bug fortran/115563] Unnecessary brackets prevent fortran vectorisation

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

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

--- Comment #4 from Andrew Pinski  ---
Note I have a fix for this which I attached to PR 68855 and will be submitting
it after the bootstrap/test finishes. Thanks again for the testcase and the
decent bug report. It definitely was useful.

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

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

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

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

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

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

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

--- Comment #9 from Andrew Pinski  ---
C version of the same:
```
void foo(_Complex float *a, int n)
{
  for(int i = 0; i < n; i++)
  {
_Complex float t;
t = a[i];
t += 6.0;
t = __builtin_assoc_barrier(t);
a[i] = t;
  }
}
```

[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #19 from Jürgen Reuter  ---
Created attachment 58476
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58476=edit
First independent reproducer

[Bug target/115408] regression between gcc 13.3.0 and 14.1.0 using -mips16 and -minterlink-mips16

[broly at mac dot com via Gcc-bugs]

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

--- Comment #13 from gagan sidhu (broly)  ---
oh i see, i didn't realise that thumb was pure 16 bit.

my apologies.

so i guess i meant thumb2, which would have the same effect of the
mips16/minterlink-mips16 flags that i use to "collapse" 32 bit executables?*

https://stackoverflow.com/a/71378041

apparently it's all called thumb though? not trying to escape your (very
welcome) correction, but i just wanted to share my surprise at learning this.

--
* often a nice savings in binary size.

of course i concede if you use a sophisticated compression algorithm on the
root file system containing these binaries, there is a significant reduction in
the benefit of the root filesystem compression (possibly even detrimental).

[Bug target/115408] regression between gcc 13.3.0 and 14.1.0 using -mips16 and -minterlink-mips16

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

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

--- Comment #12 from Andrew Pinski  ---
(In reply to gagan sidhu (broly) from comment #11)
> dear lad(ettes),
> 
> i just want to take this opportunity to contrast this scenario, had the
> equivalent occurred on the inferior, unjustifiably hyped, ARM architecture's
> "thumb" mode, which is arguably a clone of MIPS16.

Note thumb was released in 1994 while MIPS16 came out in 1996 ...

[Bug target/115408] regression between gcc 13.3.0 and 14.1.0 using -mips16 and -minterlink-mips16

[broly at mac dot com via Gcc-bugs]

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

--- Comment #11 from gagan sidhu (broly)  ---
dear lad(ettes),

i just want to take this opportunity to contrast this scenario, had the
equivalent occurred on the inferior, unjustifiably hyped, ARM architecture's
"thumb" mode, which is arguably a clone of MIPS16.

if such an unthinkable and catastrophic (/s) event occurred, my bet the team
would have pushed a 14.1.1 to resolve it. this is, of course, in spite of ARM's
inferiority.

but i get it, it's like when you have fans you always gotta satisfy the casuals
who don't even know what they're doing (why else would they use an ARM?).

at the same time it upsets me because ARM still doesn't have SMT, and i love
deferring to the embedded legend ralf baechle who never thought ARM would even
get a shot at going multicore because really, SMT can be conflated with SMP
(i'm not trying to start a rabble rabble here, so forgive me if this statement
evokes a passionate disagreement): https://tldp.org/HOWTO/SMP-HOWTO-3.html

and ralf is no fool. 

i will say, and this is of course no fault of the great gcc team, i do get
amused by the "multilib" ARM toolchain that seemingly grows with each
iteration, always (of course) incompatible with the previous one (if we use the
MIPS standard, of course. flipping a bit+resetting isn't the kind of thing i
call compatibility)

just weird how the better processors are being forgotten. i guess that's the
"industry" though and i'm comparatively young to the real maintainers in the
GNU sphere.

thanks for tolerating me, i appreciate it.

[Bug c/115566] Arrays of character type initialized with parenthesized string literals shouldn't be diagnosed with -pedantic (at least in C23)

[luigighiron at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Halalaluyafail3  ---
(In reply to Andrew Pinski from comment #3)
> C11 still has it:
> 
> 6.7.9/14:
> An array of character type may be initialized by a character string literal
> orUTF−8 string literal, optionally enclosed in braces.
> 
> 
> 
> 
> C23 still does too:
> 
> 6.7.11/15:
> 
> Anarray of character type may be initialized by a character string literal
> or UTF-8 string literal, optionally enclosed in braces. 
> 
> 
> The wording here has not changed from C90 either.
> 
> So yes GCC is correct in the pedantic warning here.

The way that I interpret this is that an array of character type may be
initialized by a character string literal, and a parenthesized string literal
has the same semantics as a string literal so it may be used as well (this text
is under the semantics section). Also, I don't see how the warning is correct
with the interpretation that it has to be specifically an expression that is a
string literal and nothing more complicated given that _Generic is accepted.

[Bug c/115566] Arrays of character type initialized with parenthesized string literals shouldn't be diagnosed with -pedantic (at least in C23)

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

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

--- Comment #5 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2004-July/144923.html

[Bug c/115566] Arrays of character type initialized with parenthesized string literals shouldn't be diagnosed with -pedantic (at least in C23)

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

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

--- Comment #4 from Andrew Pinski  ---
Note HP's aCC errored out on this code even. So it was not just something GCC
added to be extra pedantic either (this was mentioned in PR 11250 too).

[Bug c/115566] Arrays of character type initialized with parenthesized string literals shouldn't be diagnosed with -pedantic (at least in C23)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
C11 still has it:

6.7.9/14:
An array of character type may be initialized by a character string literal
orUTF−8 string literal, optionally enclosed in braces.




C23 still does too:

6.7.11/15:

Anarray of character type may be initialized by a character string literal or
UTF-8 string literal, optionally enclosed in braces. 


The wording here has not changed from C90 either.

So yes GCC is correct in the pedantic warning here.

[Bug c/115566] Arrays of character type initialized with parenthesized string literals shouldn't be diagnosed with -pedantic (at least in C23)

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

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

--- Comment #2 from Andrew Pinski  ---
>. Clang accepts this, even with -std=c89 -pedantic.

Well that is definitely a clang issue. See PR 11250 which added this warning.

[Bug ipa/115533] [12/13/14/15 regression] flac miscompiled with -O3 -march=znver2 -fipa-pta -fno-vect-cost-model since r12-3893-g6390c5047adb75

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-bisection |
Summary|[12/13/14/15 regression]|[12/13/14/15 regression]
   |flac miscompiled with -O3   |flac miscompiled with -O3
   |-march=znver2 -fipa-pta |-march=znver2 -fipa-pta
   |-fno-vect-cost-model|-fno-vect-cost-model since
   ||r12-3893-g6390c5047adb75

--- Comment #9 from Sam James  ---
r12-3893-g6390c5047adb75

[Bug rtl-optimization/115568] wrong code at -O2 with "-fno-tree-sink -fno-tree-ter -fschedule-insns" on x86_64-linux-gnu

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

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

--- Comment #1 from Andrew Pinski  ---
I wonder if the scheduler is moving the divide (by zero) incorrectly.

[Bug c++/115567] Internal Compiler Error: Segmentation Fault during build

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2024-06-20

--- Comment #1 from Andrew Pinski  ---
>See  for instructions.


First see that file since you found the bug with Ubuntu's GCC and not the
upstream GCC.

Second please read https://gcc.gnu.org/bugs/ . And provide the preprocessed
source as requested.

[Bug c++/115569] New: Internal Compiler Error: Segmentation Fault during build

[jjleksmi at gmail dot com via Gcc-bugs]

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

Bug ID: 115569
   Summary: Internal Compiler Error: Segmentation Fault during
build
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jjleksmi at gmail dot com
  Target Milestone: ---

I am facing issues while building packages using cmake and make commands. When
I run the make command it leads to an internal compiler error segmentation
fault. I also get segmentation fault (core dumped) certain times when trying to
run programs.

This is the error I am getting while trying to make a package:
```
cmakefrom /home/jjayalekshmi/gz-rendering-cpy/src/ArrowVisual.cc:18:
/usr/include/c++/11/tr1/exp_integral.tcc: In function ‘_Tp
std::__detail::__expint_En_series(unsigned int, _Tp)’:
/usr/include/c++/11/tr1/exp_integral.tcc:180:20: internal compiler error:
Segmentation fault
  180 |   if (std::abs(__del) < __eps * std::abs(__ans))
  |^~~
0x70dff104251f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x70dff1029d8f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x70dff1029e3f __libc_start_main_impl
../csu/libc-start.c:392
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [src/CMakeFiles/gz-rendering8.dir/build.make:76:
src/CMakeFiles/gz-rendering8.dir/ArrowVisual.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1626: src/CMakeFiles/gz-rendering8.dir/all]
Error 2
make: *** [Makefile:166: all] Error 2
```
And when I am trying to build
https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver?tab=readme-ov-file
I am facing the same issue:
```
/home/jjayalekshmi/workspaces/ros_ur_driver/src/ros2_control/hardware_interface/test/mock_components/test_generic_system.cpp:1639:1:
internal compiler error: Segmentation fault
1639 | }
  | ^
0x7595d264251f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
c++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
gmake[2]: *** [CMakeFiles/test_generic_system.dir/build.make:76:
CMakeFiles/test_generic_system.dir/test/mock_components/test_generic_system.cpp.o]
Error 4
gmake[1]: *** [CMakeFiles/Makefile2:437:
CMakeFiles/test_generic_system.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2
---
Failed   <<< hardware_interface [23.2s, exited with code 2]

Summary: 13 packages finished [24.7s]
  1 package failed: hardware_interface
  1 package had stderr output: hardware_interface
  30 packages not processed
```

This is my gcc version:
```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-ALHxjy/gcc-12-12.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-ALHxjy/gcc-12-12.3.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.3.0 (Ubuntu 12.3.0-1ubuntu1~22.04)
```

How can I resolve this compiler issue?

[Bug analyzer/115564] -Wanalyzer-infinite-loop false negative when there are no source locations

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-06-20
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Am testing a fix

[Bug tree-optimization/115568] New: wrong code at -O2 with "-fno-tree-sink -fno-tree-ter -fschedule-insns" on x86_64-linux-gnu

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

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

Bug ID: 115568
   Summary: wrong code at -O2 with "-fno-tree-sink -fno-tree-ter
-fschedule-insns" on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a regression from 11.*, and affects 12.* and later.

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

[524] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240620 (experimental) (GCC) 
[525] % 
[525] % gcctk -O2 small.c; ./a.out
[526] % 
[526] % gcctk -O2 -fno-tree-sink -fno-tree-ter -fschedule-insns small.c
[527] % ./a.out
Floating point exception
[528] % 
[528] % cat small.c
int a, c, d = 1, e, f = 1, h, i, j;
unsigned b = 1, g;
int main() {
  for (; h < 2; h++) {
int k = ~(b || 0), l = ((~e - j) ^ a % b) % k, m = (b ^ -1) + e;
unsigned o = ~a % ~1;
if (f) {
  l = d;
  m = 10;
  i = e;
  d = -(~e + b);
  g = o % m;
  e = -1;
n:
  a = a % ~i;
  b = ~k;
  if (!g) {
b = e + o % -1;
continue;
  }
  if (!l)
break;
}
int q = (~d + g) << ~e, p = (~d - q) & a >> b;
unsigned s = ~((g & e) + (p | (b ^ (d + k;
int r = (e & s) + p, u = d | ~a,
t = ((~(q + (~a + (s + e & u) | (-g & (c << d ^ p));
if (t)
  if (!r)
goto n;
g = m;
e = i;
  }
  return 0;
}

[Bug c++/115567] New: Internal Compiler Error: Segmentation Fault during build

[jjleksmi at gmail dot com via Gcc-bugs]

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

Bug ID: 115567
   Summary: Internal Compiler Error: Segmentation Fault during
build
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jjleksmi at gmail dot com
  Target Milestone: ---

I am facing issues while building packages using cmake and make commands. When
I run the make command it leads to an internal compiler error segmentation
fault. I also get segmentation fault (core dumped) certain times when trying to
run programs.

This is the error I am getting while trying to make a package:
```
cmakefrom /home/jjayalekshmi/gz-rendering-cpy/src/ArrowVisual.cc:18:
/usr/include/c++/11/tr1/exp_integral.tcc: In function ‘_Tp
std::__detail::__expint_En_series(unsigned int, _Tp)’:
/usr/include/c++/11/tr1/exp_integral.tcc:180:20: internal compiler error:
Segmentation fault
  180 |   if (std::abs(__del) < __eps * std::abs(__ans))
  |^~~
0x70dff104251f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x70dff1029d8f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x70dff1029e3f __libc_start_main_impl
../csu/libc-start.c:392
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [src/CMakeFiles/gz-rendering8.dir/build.make:76:
src/CMakeFiles/gz-rendering8.dir/ArrowVisual.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1626: src/CMakeFiles/gz-rendering8.dir/all]
Error 2
make: *** [Makefile:166: all] Error 2
```
And when I am trying to build
https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver?tab=readme-ov-file
I am facing the same issue:
```
/home/jjayalekshmi/workspaces/ros_ur_driver/src/ros2_control/hardware_interface/test/mock_components/test_generic_system.cpp:1639:1:
internal compiler error: Segmentation fault
1639 | }
  | ^
0x7595d264251f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
c++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
gmake[2]: *** [CMakeFiles/test_generic_system.dir/build.make:76:
CMakeFiles/test_generic_system.dir/test/mock_components/test_generic_system.cpp.o]
Error 4
gmake[1]: *** [CMakeFiles/Makefile2:437:
CMakeFiles/test_generic_system.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2
---
Failed   <<< hardware_interface [23.2s, exited with code 2]

Summary: 13 packages finished [24.7s]
  1 package failed: hardware_interface
  1 package had stderr output: hardware_interface
  30 packages not processed
```

This is my gcc version:
```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-ALHxjy/gcc-12-12.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-ALHxjy/gcc-12-12.3.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.3.0 (Ubuntu 12.3.0-1ubuntu1~22.04)
```

How can I resolve this compiler issue?

[Bug c/115566] Arrays of character type initialized with parenthesized string literals shouldn't be diagnosed with -pedantic (at least in C23)

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

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

--- Comment #1 from Andrew Pinski  ---
/* If TYPE is an array type and EXPR is a parenthesized string
   constant, warn if pedantic that EXPR is being used to initialize an
   object of type TYPE.  */

void
maybe_warn_string_init (location_t loc, tree type, struct c_expr expr)
{
  if (pedantic
  && TREE_CODE (type) == ARRAY_TYPE
  && TREE_CODE (expr.value) == STRING_CST
  && expr.original_code != STRING_CST)
pedwarn_init (loc, OPT_Wpedantic,
  "array initialized from parenthesized string constant");
}

[Bug c/115566] New: Arrays of character type initialized with parenthesized string literals shouldn't be diagnosed with -pedantic (at least in C23)

[luigighiron at gmail dot com via Gcc-bugs]

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

Bug ID: 115566
   Summary: Arrays of character type initialized with
parenthesized string literals shouldn't be diagnosed
with -pedantic (at least in C23)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luigighiron at gmail dot com
  Target Milestone: ---

GCC does not accept initializing an array of character type with a
parenthesized string literal when compiling with -pedantic, for example:

char x[]=("abc");

This causes a warning, or an error with -pedantic-errors. This should be valid
because of the following:

> A parenthesized expression is a primary expression. Its type, value, and
> semantics are identical to those of the unparenthesized expression.
Section 6.5.2 "Primary Expressions" Paragraph 6 N3220

The semantics of the expression ("abc") are equivalent to those of "abc" so
this declaration should be valid. The wording in prior versions was not so
clear that the semantics are the same, but I assume the intent was still to
allow this. Clang accepts this, even with -std=c89 -pedantic. MSVC accepts this
with all warnings enabled. Interestingly, GCC correctly accepts using _Generic
expressions which have a string literal as the selected branch to be used in
initialization of an array of character type:

char x[]=_Generic(0,int:"abc");

Parenthesizing the _Generic expression or the string literal itself causes GCC
to create a warning again. Multiple nested _Generic expressions works as well.

[Bug c++/95763] Feature request: compiler warning if line width exceeds N symbols

[mlevine55 at bloomberg dot net via Gcc-bugs]

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

Michael Levine  changed:

   What|Removed |Added

 CC||mlevine55 at bloomberg dot net

--- Comment #6 from Michael Levine  ---
Has there been an effort already to add a code style checker as part of GCC,
similar to clang-tidy?

[Bug rtl-optimization/115565] [11/12/13/14/15 Regression] CSE: Comparison incorrectly evaluated as constant causing optimization to produce wrong code

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-20
 Status|UNCONFIRMED |NEW
 CC||roger at nextmovesoftware dot 
com
 Ever confirmed|0   |1

--- Comment #3 from Roger Sayle  ---
Doh!  I hadn't noticed (twenty years ago) that -1 was used to represent an
invalid quantity number in CSE's comparison_qty field.  There was no mention of
this in my post or patch. Using INT_MIN looks like a reasonable (good) fix. 
Presumably backends that constrain values in hard register zero (before reload)
are rare, which is why no-one has noticed/been affected by this.

Thanks for the fix, and my apologies for the inconvenience.

[Bug rtl-optimization/115565] [4.0/4.1/4.2/4.3/4.4/4.5/4.6/4.7/4.8/4.9/5/6/7/8/9/10/11/12/13/14/15 Regression] CSE: Comparison incorrectly evaluated as constant causing optimization to produce wrong c

[macro at orcam dot me.uk via Gcc-bugs]

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

--- Comment #2 from Maciej W. Rozycki  ---
Created attachment 58475
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58475=edit
Reduced reproducer and incorrect code + RTL dumps produced with commit
08a692679fb8

[Bug rtl-optimization/115565] [4.0/4.1/4.2/4.3/4.4/4.5/4.6/4.7/4.8/4.9/5/6/7/8/9/10/11/12/13/14/15 Regression] CSE: Comparison incorrectly evaluated as constant causing optimization to produce wrong c

[macro at orcam dot me.uk via Gcc-bugs]

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

--- Comment #1 from Maciej W. Rozycki  ---
Created attachment 58474
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58474=edit
Reduced reproducer and correct code + RTL dumps produced with commit
4cd26879f758

[Bug rtl-optimization/115565] New: [4.0/4.1/4.2/4.3/4.4/4.5/4.6/4.7/4.8/4.9/5/6/7/8/9/10/11/12/13/14/15 Regression] CSE: Comparison incorrectly evaluated as constant causing optimization to produce wr

[macro at orcam dot me.uk via Gcc-bugs]

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

Bug ID: 115565
   Summary: [4.0/4.1/4.2/4.3/4.4/4.5/4.6/4.7/4.8/4.9/5/6/7/8/9/10/
11/12/13/14/15 Regression] CSE: Comparison incorrectly
evaluated as constant causing optimization to produce
wrong code
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: macro at orcam dot me.uk
  Target Milestone: ---

Created attachment 58473
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58473=edit
Proposed fix

I've had an emergency case where I chose to revive my old Alpha/Linux
userland based on glibc 2.4 + LinuxThreads built with GCC 4.1.2 release,
which I built decades ago, but never came to verifing.  Now that I came
back to it I found out that numerous key programs hang, making the system
mostly unusable.  Oddly enough bash and GDB worked, which let me debug
this issue over a serial console line in a single-user environment.

Eventually I figured out that a key piece of code has been optimised away
from `pthread_rwlock_unlock' in libpthread.so, causing a write lock never
to be released and consequently the caller to lock up on the next attempt
to reacquire the lock.

Then I have narrowed the problem down to CSE and bisected to commit
08a692679fb8 ("Undefined cse.c behaviour causes 3.4 regression on HPUX"),
, staring at
which however and wading through cse.c yielded nothing.

So I went ahead and debugged GCC compiling the problematic piece of code
and finally arrived at this condition:

REG_QTY (REGNO (folded_arg1)) == ent->comparison_qty

incorrectly evaluating to true for `ent' being a memory reference.
Needless to say the left-hand side referred to register 0, so both `qty'
values were -1, for this source code:

rwlock->__rw_writer != thread_self ()

where `thread_self' expanded to a PALcode call to retrieve the thread
pointer and return it in $0.  Evidently an update to the handling of
`comparison_qty' was missed with said commit and -1 now means either
a non-register reference or a register 0 reference that has not been
assigned a quantity.  I have attached an obvious fix for this issue and
will follow with a proper patch submission right away.

Interestingly enough the bug has been covered for my reproducer later on
and as from commit 932ad4d9b550 ("Make CSE path following use the CFG"),
, it does not
trigger anymore with the original reproducer (and LinuxThreads have
since been decommissioned anyway, so nobody else might have stumbled
across this issue), however in principle the bug is still there waiting
to bite and the fix proposed cleanly applies unchanged from the version
I originally made for GCC 4.1.2 except for the .c to .cc file rename.

As there can only be a single attachment added per submission, I'll be
following up with tarballs including the reproducer, Alpha assembly code
produced and associated RTL dumps for the last good and first bad commit
respectively, so that this has been recorded for posterity, even though
not directly usable with GCC 15.  See the .cmd files within for the
compilation options used, although just `-O1' should do.

[Bug fortran/115559] [OpenMP] 'link' clause of 'declare target' causes link errors

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

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

--- Comment #4 from Tobias Burnus  ---
NOTE to self: This code now adds the attribute unconditionally. For COMMON and
MODULE it makes sense; but for programm/subroutine/function, it needs to be
rechecked whether that variable is actually used.

An example where the variable is in the main program and the user is in a
contained subroutine fails – i.e. simply excluding that case will not work. But
maybe the decl can be avoided at least in some cases.

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

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

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

--- Comment #8 from Andrew Pinski  ---
Note the handling of PAREN_EXPR in tree-complex.c has been inefficient since
the tree code was added back in r0-85884-gdedd42d511b6e4 .

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
I have a patch to tree-complex.cc to better handle PAREN_EXPR . It will fix
both the 465.tonto issue and PR 115563.

[Bug fortran/115559] [OpenMP] 'link' clause of 'declare target' causes link errors

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
Created attachment 58472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58472=edit
Patch that calls symtab_node::get_create in the FE

This patch does now likewise – calling symtab_node::get_create in the FE. Note:
It's get_create as 'get' returns NULL.

That seems to fix the issue for the example of comment 0. (Which obviously
fails at runtime as nothing is mapped).

For the OpenMP examples' testcase devices/sources/declare_target.6.f90 [marked
as compile-time only test; see link in comment 0] it fails during final linking
and shows messages like:
>  relocation truncated to fit: R_X86_64_32S against symbol `__m_dat_MOD_sv1' 
> defined in .bss section in a-declare_target.6.o

and
>  undefined reference to `s_output

The latter is clear – as the file calls but does not provide those functions.

And the former as well:
   integer, parameter :: N=1
   real :: sp(N), sv1(N), sv2(N)
   double precision :: dp(N), dv1(N), dv2(N)

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

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Matthias Kretz
:

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

commit r11-11517-ga0b92a530ad61389c0cdeb8d8ece4677e019c28e
Author: Matthias Kretz 
Date:   Fri Jun 14 15:11:25 2024 +0200

libstdc++: Fix find_last_set(simd_mask) to ignore padding bits

With the change to the AVX512 find_last_set implementation, the change
to AVX512 operator!= is unnecessary. However, the latter was not
producing optimal code and unnecessarily set the padding bits. In
theory, the compiler could determine that with the new !=
implementation, the bit operation for clearing the padding bits is a
no-op and can be elided.

Signed-off-by: Matthias Kretz 

libstdc++-v3/ChangeLog:

PR libstdc++/115454
* include/experimental/bits/simd_x86.h (_S_not_equal_to): Use
neq comparison instead of bitwise negation after eq.
(_S_find_last_set): Clear unused high bits before computing
bit_width.
* testsuite/experimental/simd/pr115454_find_last_set.cc: New
test.

(cherry picked from commit 4787960dcaf0de3f46464960f5246de9b3c69a06)

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

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Matthias Kretz
:

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

commit r14-10331-ge77f314ccd422ffa05c6c06837e2cb94c25f2bba
Author: Matthias Kretz 
Date:   Fri Jun 14 15:11:25 2024 +0200

libstdc++: Fix find_last_set(simd_mask) to ignore padding bits

With the change to the AVX512 find_last_set implementation, the change
to AVX512 operator!= is unnecessary. However, the latter was not
producing optimal code and unnecessarily set the padding bits. In
theory, the compiler could determine that with the new !=
implementation, the bit operation for clearing the padding bits is a
no-op and can be elided.

Signed-off-by: Matthias Kretz 

libstdc++-v3/ChangeLog:

PR libstdc++/115454
* include/experimental/bits/simd_x86.h (_S_not_equal_to): Use
neq comparison instead of bitwise negation after eq.
(_S_find_last_set): Clear unused high bits before computing
bit_width.
* testsuite/experimental/simd/pr115454_find_last_set.cc: New
test.

(cherry picked from commit 1340ddea0158de3f49aeb75b4013e5fc313ff6f4)

[Bug analyzer/115564] New: -Wanalyzer-infinite-loop false negative when there are no source locations

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

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

Bug ID: 115564
   Summary: -Wanalyzer-infinite-loop false negative when there are
no source locations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Consider e.g.:

void test (unsigned b)
{
for (unsigned i = b; i >= 0; --i) {
}
}

-Wanalyzer-infinite-loop warns about this at -O1 and below:
  https://godbolt.org/z/axze96331

but at -O2 and above we don't warn. 
  https://godbolt.org/z/xjGMnP3P5

The warning is rejected at:

  if (inf_loop->m_loc == UNKNOWN_LOCATION)
{
  if (get_logger ())
get_logger ()->log
  ("no location available for reporting infinite loop");
  continue;
}

We have two basic blocks no statements, and location_t == UNKNOWN_LOCATION on
each of the edges connecting them.

Ideas for fixing:
* backtrack through the egraph to find the first useful location_t on a path to
the entry to the infinite loop
* ensure that location_t values are set on the CFG edges

[Bug rtl-optimization/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3 since r15-1042-g68b0742a49d

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

Summary|[15 Regression] ICE in  |[15 Regression] ICE in
   |smallest_mode_for_size, at  |smallest_mode_for_size, at
   |stor-layout.cc:356 during   |stor-layout.cc:356 during
   |combine on RISC-V   |combine on RISC-V
   |rv64gcv_zvl256b at -O3  |rv64gcv_zvl256b at -O3
   ||since r15-1042-g68b0742a49d

--- Comment #5 from Patrick O'Neill  ---
Bisected to first bad commit: r15-1042-g68b0742a49d

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

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

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

--- Comment #6 from Andrew Pinski  ---
I wonder if lower complex should do a better job in the first place:
that is from:
  _9 = _8 + __complex__ (6.0e+0, 1.0e+0);
  _11 = ((_9));
  (*a_7(D))[_6] = _11;

instead of producing:
  _9 = COMPLEX_EXPR <_15, _14>;
  _11 = ((_9));
  _19 = REALPART_EXPR <_11>;
  _20 = IMAGPART_EXPR <_11>;

It should produce:
  _19 = ((_15));
  _20 = ((_24));

Instead. that is expand PAREN_EXPR into its components.

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

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

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

--- Comment #5 from Andrew Pinski  ---
Note a good testcase for this is (with `-O3 -ffast-math -fopenmp-simd`):
```

subroutine foo(a,n)

  complex (kind(1d0)) :: a(*)
  integer :: i,n

!$OMP SIMD
  do i=1,n
 a(i)=(a(i)+(6d0,1d0))
  enddo

end subroutine foo
```

(from PR 115563).

[Bug fortran/115563] Unnecessary brackets prevent fortran vectorisation

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

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

--- Comment #3 from Andrew Pinski  ---
Note the full IR:

  _9 = COMPLEX_EXPR <_15, _14>;
  _11 = ((_9));
  _19 = REALPART_EXPR <_11>;
  _20 = IMAGPART_EXPR <_11>;
  REALPART_EXPR <(*a_7(D))[_6]> = _19;
  IMAGPART_EXPR <(*a_7(D))[_6]> = _20;

Yes it is a dup.
// (()) is PAREN_EXPR .

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mjr19 at cam dot ac.uk

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

[Bug fortran/115563] Unnecessary brackets prevent fortran vectorisation

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup.

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

[Bug fortran/115563] Unnecessary brackets prevent fortran vectorisation

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---

  _11 = ((_9));
  _19 = REALPART_EXPR <_11>;
  _20 = IMAGPART_EXPR <_11>;
  REALPART_EXPR <(*a_7(D))[_6]> = _19;
  IMAGPART_EXPR <(*a_7(D))[_6]> = _20;

[Bug fortran/115563] New: Unnecessary brackets prevent fortran vectorisation

[mjr19 at cam dot ac.uk via Gcc-bugs]

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

Bug ID: 115563
   Summary: Unnecessary brackets prevent fortran vectorisation
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjr19 at cam dot ac.uk
  Target Milestone: ---

The code

subroutine foo(a,n)

  complex (kind(1d0)) :: a(*)
  integer :: i,n

!$OMP SIMD
  do i=1,n
 a(i)=(a(i)+(6d0,1d0))
  enddo

end subroutine foo

compiled with

$ gfortran-14 -S -O3 -ffast-math -fopenmp-simd  -mavx2 t3.f90

does not vectorise.

$ grep -c ymm t3.s 
0

If the extra brackets are removed, so that the loop line reads

 a(i)=a(i)+(6d0,1d0)

then it does.

$ grep -c ymm t3.s 
3

It seems surprising that the code produced should differ depending on whether
the brackets are present, as I do not believe that they alter the meaning of
the code in any way. One can construct many similar examples, e.g. using a
complex variable in the place of the (6d0,1d0), or using a real constant, etc.

[Bug target/115526] [14/15 regression] invalid assember emitted for alpha, "Error: duplicate !tlsgd!62"

[dilfridge at gentoo dot org via Gcc-bugs]

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

--- Comment #4 from Andreas K. Huettel  ---
Here's what cvise came up with as minimal test case.

1) compile command:
alpha-unknown-linux-gnu-gcc -c -fno-strict-overflow -Wsign-compare -mieee
-DNDEBUG -mieee -pipe -O2 -mcpu=ev4 -fwrapv -std=c11 \
   -Wextra -Wno-unused-parameter -Wno-missing-field-initializers
-Wstrict-prototypes -Werror=implicit-function-declaration \
   -fvisibility=hidden -fPIC -DPy_BUILD_CORE  -o test $1

2) interestingness test:
/home/huettel/alpha-bug/compile.sh dtoa.i 2>&1 | grep 'Error: duplicate
!tlsgd!'

3) output:
==
struct _ts {
  struct _dtoa_state *interp
};
struct Bigint {
  int k
} *_Py_dg_strtod_bs;
struct _dtoa_state {
  struct Bigint p5s;
  struct Bigint *freelist[]
};
extern _Thread_local struct _ts _Py_tss_tstate;
typedef struct Bigint Bigint;
int pow5mult_k;
long _Py_dg_strtod_ndigits;
void PyMem_Free();
void Bfree(Bigint *v) {
  if (v)
if (v->k)
  PyMem_Free();
else {
  struct _dtoa_state *interp = _Py_tss_tstate.interp;
  interp->freelist[v->k] = v;
}
}
static Bigint *pow5mult(Bigint *b) {
  for (;;) {
if (pow5mult_k & 1) {
  Bfree(b);
  if (b == 0)
return 0;
}
if (!(pow5mult_k >>= 1))
  break;
  }
}
void _Py_dg_strtod() {
  if (_Py_dg_strtod_ndigits)
pow5mult(_Py_dg_strtod_bs);
}
==

4) double-check:
huettel@crossdev ~/alpha-bug $ ./compile.sh dtoa.i
dtoa.i:3:1: warning: no semicolon at end of struct or union
3 | };
  | ^
dtoa.i:6:1: warning: no semicolon at end of struct or union
6 | } *_Py_dg_strtod_bs;
  | ^
dtoa.i:10:1: warning: no semicolon at end of struct or union
   10 | };
  | ^
dtoa.i:15:1: warning: function declaration isn’t a prototype
[-Wstrict-prototypes]
   15 | void PyMem_Free();
  | ^~~~
dtoa.i:36:6: warning: function declaration isn’t a prototype
[-Wstrict-prototypes]
   36 | void _Py_dg_strtod() {
  |  ^
{standard input}: Assembler messages:
{standard input}:140: Error: duplicate !tlsgd!6

[Bug fortran/115559] [OpenMP] 'link' clause of 'declare target' causes link errors

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

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

--- Comment #2 from Tobias Burnus  ---
For C, it is actually handled in the FE for

  tree at1 = lookup_attribute ("omp declare target", DECL_ATTRIBUTES (t));
  tree at2 = lookup_attribute ("omp declare target link",
   DECL_ATTRIBUTES (t));
  only_device_type_or_indirect = false;
  if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_LINK)
{   
  id = get_identifier ("omp declare target link");
  std::swap (at1, at2);
}
...
  if (!at1)
{
  DECL_ATTRIBUTES (t) = tree_cons (id, NULL_TREE, DECL_ATTRIBUTES (t));
  if (TREE_CODE (t) != FUNCTION_DECL && !is_global_var (t))
continue;

  symtab_node *node = symtab_node::get (t);
  if (node != NULL)
{
  node->offloadable = 1;
  if (ENABLE_OFFLOADING)
{
  g->have_offload = true;
  if (is_a  (node))
vec_safe_push (offload_vars, t);
}
}

[Bug c++/115561] [14/15 Regression] ICE checking constraints when a local class is involved since r14-9659

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

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

Patrick Palka  changed:

   What|Removed |Added

  Known to fail||14.1.0, 15.0
 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
  Known to work||13.3.0
   Last reconfirmed||2024-06-20
   Target Milestone|--- |14.2
 Ever confirmed|0   |1
Summary|[14/15 Regression] ICE  |[14/15 Regression] ICE
   |checking constraints when a |checking constraints when a
   |local class is involved |local class is involved
   ||since r14-9659

--- Comment #1 from Patrick Palka  ---
Confirmed, seems the ICE started with r14-9659.

[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases

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

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

Bug 11 Summary: [Ranger] deduce 'a >= 0' from  'b << a'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11

   What|Removed |Added

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

[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

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

[Bug middle-end/115555] [Ranger] deduce 'a >= 0' from 'b << a'

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Yes it is a dup.

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

[Bug middle-end/115555] [Ranger] deduce 'a >= 0' from 'b << a'

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
I think this might be a dup.

[Bug target/115562] RISC-V: ICE because of reused fndecl with target-arch attribute

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

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

--- Comment #1 from Christoph Müllner  ---
This issue was discovered while analyzing a build issue with a patchset
to introduce optimized string processing routines for RISC-V in glibc.

See also:
  https://sourceware.org/pipermail/libc-alpha/2024-June/157627.html

[Bug target/115562] New: RISC-V: ICE because of reused fndecl with target-arch attribute

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

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

Bug ID: 115562
   Summary: RISC-V: ICE because of reused fndecl with target-arch
attribute
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cmuellner at gcc dot gnu.org
  Target Milestone: ---

Minimal (?) reproducer:

$ cat foo-copy.c 
void foo (void);

__attribute__((target("arch=+zbb")))
void*
memcpy (void *d, const void *, unsigned long)
{
  return d;
}
__attribute__((target("arch=+zbb"))) void fun0(void) {}
__attribute__((target("arch=+zbb"))) void fun1(void) {}
__attribute__((target("arch=+zbb"))) void fun2(void) {}
__attribute__((target("arch=+zbb"))) void fun3(void) {}
__attribute__((target("arch=+zbb"))) void fun4(void) {}
__attribute__((target("arch=+zbb"))) void fun5(void) {}
__attribute__((target("arch=+zbb"))) void fun6(void) {}
__attribute__((target("arch=+zbb"))) void fun7(void) {}
__attribute__((target("arch=+zbb"))) void fun8(void) {}
__attribute__((target("arch=+zbb"))) void fun9(void) {}
__attribute__((target("arch=+zbb"))) void fun10(void) {}
__attribute__((target("arch=+zbb"))) void fun11(void) {}
__attribute__((target("arch=+zbb"))) void fun12(void) {}

This is similar to PR115554, but triggers the assertion in
riscv_func_target_put()
because when processing `fun12` the fndecl is equal to the previously processed
fndecl of `memcpy`. I.e., the assumption that the fndecl pointer can be used as
an identifier (or comparable for the hash-table) does not hold.

Like PR115554, this bug is part of GCC14 and on the master branch.

The ICE looks the same as for PR115554 (the same assertion is triggered).
To analyze this issue, I've extended riscv_func_target_put() like this:

+  if (*target_info_slot)
+{
+  inform (loc, "Hash collision detected:");
+  inform (loc, "  old function: %qE (%p)", (*target_info_slot)->fn_decl,
(*target_info_slot)->fn_decl);
+  inform (loc, "  old attributes: %s",
(*target_info_slot)->fn_target_name.c_str());
+  inform (loc, "  new function: %qE", fn_decl);
+  inform (loc, "  new attributes: %s", fn_target_name.c_str ());
+}
+  else
+{
+  inform (loc, "Adding target attributes to function:");
+  inform (loc, "  new function: %qE (%p)", fn_decl, fn_decl);
+  inform (loc, "  new attributes: %s", fn_target_name.c_str ());
+}
   gcc_assert (!*target_info_slot);

Additionally, I've included tree.h and added "location_t loc" as parameter
of this function. This gives the following output on the reproducer above:

$ /opt/riscv-mainline/bin/riscv64-unknown-linux-gnu-gcc -c foo-copy.c
foo-copy.c:5:1: note: Adding target attributes to function: 
5 | memcpy (void *d, const void *, unsigned long)   
  | ^~
foo-copy.c:5:1: note:   new function: 'memcpy' (0x7f295879e200)  // first
appearance
foo-copy.c:5:1: note:   new attributes:
rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zbb1p0
 
foo-copy.c:10:43: note: Adding target attributes to function:
   10 | __attribute__((target("arch=+zbb"))) void fun0(void) {}
  |   ^~~~
foo-copy.c:10:43: note:   new function: 'fun0' (0x7f295879e400)
foo-copy.c:10:43: note:   new attributes:
rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zbb1p0
[...]
foo-copy.c:22:43: note: Adding target attributes to function:
   22 | __attribute__((target("arch=+zbb"))) void fun11(void) {}
  |   ^
foo-copy.c:22:43: note:   new function: 'fun11' (0x7f295879ef00)
foo-copy.c:22:43: note:   new attributes:
rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zbb1p0
foo-copy.c:23:43: note: Hash collision detected:
   23 | __attribute__((target("arch=+zbb"))) void fun12(void) {}
  |   ^
foo-copy.c:23:43: note:   old function: 'fun12' (0x7f295879e200)  // same
address!
foo-copy.c:23:43: note:   old attributes:
rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zbb1p0
foo-copy.c:23:43: note:   new function: 'fun12'
foo-copy.c:23:43: note:   new attributes:
rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zbb1p0
foo-copy.c:23:1: internal compiler error: in riscv_func_target_put, at
common/config/riscv/riscv-common.cc:536
   23 | __attribute__((target("arch=+zbb"))) void fun12(void) {}
  | ^

As can be seen in the example above, fndecl of `memcpy` has the address
0x7f295879e200, which is equal to the address of fndecl of `fun12`.

Note that even small adjustments to the source will break the reproducer.
Therefore, I could not rename `memcpy` to something different.

[Bug c++/115561] New: [14/15 Regression] ICE checking constraints when a local class is involved

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 115561
   Summary: [14/15 Regression] ICE checking constraints when a
local class is involved
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Reduced test case:

template
auto declval() noexcept -> _Tp&&;

template
struct enable_if
{ };

template
struct enable_if
{ using type = _Tp; };

template
using enable_if_t = typename enable_if<_Cond, _Tp>::type;

template
struct is_void
{ static constexpr bool value = false;  };

template
using invoke_result_t =
decltype(declval()(declval()...));

template
using iter_reference_t = decltype(*declval());

struct iter_move_fn
{
template
constexpr
auto operator() (I &)  -> void;
} iter_move;

template
using iter_rvalue_reference_t = decltype(iter_move(declval()));

template
concept same_as = true;

template
concept readable_concept_ =
same_as, iter_rvalue_reference_t>;

template
concept indirectly_readable =
readable_concept_>;

template
using indirect_result_t =
enable_if_t,
invoke_result_t>>;

template
concept transformable =
   (!is_void>::value);

template
requires transformable
constexpr void transform(I, Fun)
{
}

void foo()
{
struct B {};
(void) transform((B*)nullptr, [](B) {return 0; });
}

With GCC 14.1, g++ -std=c++20 crashes:

test2.cpp: In substitution of ‘template  requires 
transformable constexpr void transform(I, Fun) [with I = foo()::B*; Fun
= foo()::]’:
test2.cpp:65:21:   required from here
   65 | (void) transform((B*)nullptr, [](B) {return 0; });
  |~^
test2.cpp:34:51: internal compiler error: Segmentation fault
   34 | using iter_rvalue_reference_t = decltype(iter_move(declval()));
  |  ~^~~~
0xe9ea2f crash_signal
../../gcc/toplev.cc:319
0x8fc014 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.cc:2971
0x8c9cd7 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:21081
0x8ce166 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:16929
0x8cf7a4 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:13923
0x77dfbf normalize_concept_check
../../gcc/cp/constraint.cc:761
0x77dfbf normalize_atom
../../gcc/cp/constraint.cc:816
0x77dfbf normalize_expression
../../gcc/cp/constraint.cc:886
0x77e5f1 normalize_concept_check
../../gcc/cp/constraint.cc:795
0x77e5f1 normalize_atom
../../gcc/cp/constraint.cc:816
0x77e5f1 normalize_expression
../../gcc/cp/constraint.cc:886
0x780070 get_normalized_constraints
../../gcc/cp/constraint.cc:898
0x780070 normalize_concept_definition
../../gcc/cp/constraint.cc:1016
0x780070 satisfy_nondeclaration_constraints
../../gcc/cp/constraint.cc:3225
0x780070 constraint_satisfaction_value
../../gcc/cp/constraint.cc:3411
0x78275e evaluate_concept_check(tree_node*)
../../gcc/cp/constraint.cc:3459
0x76d7e3 cxx_eval_constant_expression
../../gcc/cp/constexpr.cc:8519
0x7740b7 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.cc:8857
0x777bd5 maybe_constant_value(tree_node*, tree_node*, mce_value)
../../gcc/cp/constexpr.cc:9145
0x8cada4 convert_nontype_argument
../../gcc/cp/pt.cc:7521

Also crashes on godbolt GCC trunk. GCC 13.2 compiles this OK. Moving the
definition of struct B to global scope makes the crash go away.

[Bug libstdc++/115497] [15 Regression] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #16 from Jonathan Wakely  ---
Patches series to eradicate __is_pointer, __is_scalar and __is_void posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655268.html

[Bug libstdc++/109150] std::fill should use __gnu_cxx::__is_scalar overloads for all scalars

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655267.html

[Bug libstdc++/90276] PSTL tests fail in Debug Mode

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

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

--- Comment #16 from Jonathan Wakely  ---
Two patches posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655274.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655273.html

[Bug ipa/115533] [12/13/14/15 regression] flac miscompiled with -O3 -march=znver2 -fipa-pta -fno-vect-cost-model

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

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

--- Comment #7 from Sam James  ---
Created attachment 58471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58471=edit
test.c

Attached a first cut of a reduction, I still have more to do though.

[Bug ipa/115533] [12/13/14/15 regression] flac miscompiled with -O3 -march=znver2 -fipa-pta -fno-vect-cost-model

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

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

--- Comment #8 from Sam James  ---
(In reply to Richard Biener from comment #5)
> I wonder if it's the badly tested interaction between IPA opts and IPA PTA,
> I assume -O2 -ftree-vectorize instead of -O3 isn't enough to reproduce?
> 

It isn't, surprisingly. It was also really sensitive to vectorisation -- for a
while, novector on one loop was enough, but it stopped being after reduction.
We'll see..

[Bug c++/115560] New: ICE: in type_dependent_expression_p, at cp/pt.cc:28576

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

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

Bug ID: 115560
   Summary: ICE: in type_dependent_expression_p, at cp/pt.cc:28576
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  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 in type_dependent_expression_p when
compiling the provided code with the specified options. 
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
***
# g++ -v
Using built-in specs.
COLLECT_GCC=g++
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 source_code_1.cpp

struct C { void f(auto) noexcept; };
void C::f(auto) noexcept(C::x) {}


***
Command Lines:
# g++ source_code_1.cpp  -std=c++2a -Wall -Wextra -pedantic
-fsanitize=undefined -fsanitize=address -O2 -c -o source_code_1.o
source_code_1.cpp:3:29: error: ‘x’ is not a member of ‘C’
3 | void C::f(auto) noexcept(C::x) {}
  | ^
source_code_1.cpp:3:6: error: declaration of ‘void C::f(auto:2)’ has a
different exception specifier
3 | void C::f(auto) noexcept(C::x) {}
  |  ^
source_code_1.cpp:2:17: note: from previous declaration ‘void C::f(auto:1)
noexcept’
2 | struct C { void f(auto) noexcept; };
  | ^
source_code_1.cpp:3:30: internal compiler error: in
type_dependent_expression_p, at cp/pt.cc:28576
3 | void C::f(auto) noexcept(C::x) {}
  |  ^
0x82608a type_dependent_expression_p(tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:28576
0xcac924 instantiation_dependent_r
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:28781
0x16e163c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/root/gdbtest/gcc/obj/../gcc/gcc/tree.cc:11468
0x16e4db5 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
/root/gdbtest/gcc/obj/../gcc/gcc/tree.cc:11728
0xca8299 instantiation_dependent_uneval_expression_p(tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:28810
0xca8299 instantiation_dependent_expression_p(tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:28820
0xca832c uses_template_parms(tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:11129
0xb5e638 duplicate_decls(tree_node*, tree_node*, bool, bool)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/decl.cc:2662
0xb628c6 grokfndecl
/root/gdbtest/gcc/obj/../gcc/gcc/cp/decl.cc:11094
0xb69a7b grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/decl.cc:15114
0xb6d066 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/decl.cc:18212
0xc83107 cp_parser_function_definition_from_specifiers_and_declarator
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:32780
0xc83107 cp_parser_init_declarator
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:23451
0xc5668f cp_parser_simple_declaration
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:15958
0xc8ffea cp_parser_declaration
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:15631
0xc90fea cp_parser_toplevel_declaration
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:15652
0xc90fea cp_parser_translation_unit
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:5284
0xc90fea c_parse_file()
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:51440
0xddf371 c_common_parse_file()
/root/gdbtest/gcc/obj/../gcc/gcc/c-family/c-opts.cc:1311
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for 

[Bug fortran/115559] [OpenMP] 'link' clause of 'declare target' causes link errors

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

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

--- Comment #1 from Tobias Burnus  ---
Looks as if offload_vars is empty in case of Fortran; the variables are tagged
as 'declare variant link' in the FE but varpool_node::get_create has:

  if ((flag_openacc || flag_openmp)
  && lookup_attribute ("omp declare target", DECL_ATTRIBUTES (decl)))
{
  node->offloadable = 1;
  if (ENABLE_OFFLOADING && !DECL_EXTERNAL (decl))
{
  g->have_offload = true;
  if (!in_lto_p)
vec_safe_push (offload_vars, decl);
}
}

Thus, somewhere a "omp declare target" decl needs to exist.

[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||malat at debian dot org

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

[Bug target/115556] error: this operation requires the SVE ISA extension

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=115403
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Andrew Pinski  ---
Yes this is a dup of bug 109753.

The trunk issue is PR 115403 .

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

[Bug target/115556] error: this operation requires the SVE ISA extension

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||109753

--- Comment #5 from Andrew Pinski  ---
The GCC 13/14 issue is really PR 109753.
The trunk issue is most likely related to PR 115403 .


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753
[Bug 109753] [13/14 Regression] pragma GCC target causes std::vector not to
compile (always_inline on constructor)

[Bug target/115556] error: this operation requires the SVE ISA extension

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

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

--- Comment #4 from Andrew Pinski  ---
The trunk error message might be better:
```
In file included from
/opt/compiler-explorer/libs/highway/trunk/hwy/highway.h:588,
 from
/opt/compiler-explorer/libs/highway/trunk/hwy/contrib/math/math-inl.h:28,
 from ./example.cpp:5,
 from
/opt/compiler-explorer/libs/highway/trunk/hwy/foreach_target.h:163,
 from :4:
/opt/compiler-explorer/libs/highway/trunk/hwy/ops/arm_neon-inl.h: In function
'hwy::N_NEON::Vec128
hwy::N_NEON::detail::BitCastToByte(hwy::N_NEON::Vec128)':
/opt/compiler-explorer/libs/highway/trunk/hwy/ops/arm_neon-inl.h:829:23: error:
inlining failed in call to 'always_inline' 'hwy::N_NEON::Vec128::Vec128(Raw) [with T = unsigned char; long unsigned int N = 16]': target
specific option mismatch
  829 |   HWY_INLINE explicit Vec128(const Raw raw) : raw(raw) {}
  |   ^~
/opt/compiler-explorer/libs/highway/trunk/hwy/ops/arm_neon-inl.h:83:72: note:
called from here
   83 | HWY_NEON_EVAL(prefix##infix##suffix,
HWY_NEON_BUILD_ARG_##args));\
  |   
^
/opt/compiler-explorer/libs/highway/trunk/hwy/ops/arm_neon-inl.h:124:3: note:
in expansion of macro 'HWY_NEON_DEF_FUNCTION'
  124 |   HWY_NEON_DEF_FUNCTION(uint32, 4, name, prefix##q, infix, u32, args) \
  |   ^
/opt/compiler-explorer/libs/highway/trunk/hwy/ops/arm_neon-inl.h:1421:1: note:
in expansion of macro 'HWY_NEON_DEF_FUNCTION_UINT_32'
 1421 | HWY_NEON_DEF_FUNCTION_UINT_32(BitCastToByte, vreinterpret, _u8_,
HWY_CAST_TO_U8)
  | ^
```

[Bug libstdc++/51452] [DR 2116] is_nothrow_.*constructible bugs

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

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

--- Comment #18 from Andrew Pinski  ---
Related to https://cplusplus.github.io/CWG/issues/2886.html also.

[Bug fortran/115559] New: [OpenMP] 'link' clause of 'declare target' causes link errors

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

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

Bug ID: 115559
   Summary: [OpenMP] 'link' clause of 'declare target' causes link
errors
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: openmp, rejects-valid, wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

A C version of the following program compiles — for Fortran, the offload-device
LTO fails with:

link.f90:3:16: error: variable 'aaa' has been referenced in offloaded code but
hasn't been marked to be included in the offloaded code


module m
  implicit none
  integer :: AAA, BBB(10)
  !$omp declare target link(AAA,BBB)
end module m

subroutine sub()
  !$omp declare target
  use m
  implicit none
  AAA = 1
  BBB(5) = 7
end

external sub
!$omp target
  call sub
!$omp end target
end


Same issue for the larger (and more proper) OpenMP examples testcase:

https://github.com/OpenMP/Examples/blob/main/devices/sources/declare_target.6.f90

[Bug c++/114844] A trivial but noexcept(false) destructor is incorrectly considered non-throwing

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

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

--- Comment #2 from Andrew Pinski  ---
https://cplusplus.github.io/CWG/issues/2886.html

The DR report is still have not been accepted here ...

[Bug c++/115558] Trivial noexcept(false) default constructor does not make value initialization potentially throwing

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I see this was just accepted as a defect report this year even:
[Accepted as a DR at the March, 2024 meeting.]

[Bug c++/115558] Trivial noexcept(false) default constructor does not make value initialization potentially throwing

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

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

--- Comment #1 from Andrew Pinski  ---
See https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00311.html .

[Bug c++/115558] New: Trivial noexcept(false) default constructor does not make value initialization potentially throwing

[mital at mitalashok dot co.uk via Gcc-bugs]

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

Bug ID: 115558
   Summary: Trivial noexcept(false) default constructor does not
make value initialization potentially throwing
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mital at mitalashok dot co.uk
  Target Milestone: ---

This is related to DR2820 https://cplusplus.github.io/CWG/issues/2820.html

struct X {
X() noexcept(false) = default;
};
static_assert(!noexcept(X()));  // Should pass, but does not

Similar to Bug 114844 and https://cplusplus.github.io/CWG/issues/2886.html

[Bug fortran/114825] [11 Regression] Compiler error using gfortran and OpenMP since r5-1190

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Fixed for 11.5 as well.

[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

   Target Milestone|--- |11.5
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #9 from Jakub Jelinek  ---
Fixed for 11.5 as well.

[Bug sanitizer/114956] [11 Regression] Segmentation fault with -fsanitize=address -fsanitize=null -O2 when attribute no_sanitize_address is enabled since r9-5742

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Fixed for 11.5 as well.

[Bug c++/114691] [11 Regression] Bogus ignoring loop annotation warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Fixed for 11.5 as well.

[Bug tree-optimization/114876] [11 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #14 from Jakub Jelinek  ---
Fixed for 11.5 as well.

[Bug c++/114634] [11 Regression] Crash Issue Encountered in GCC Compilation of Template Code with Aligned Attribute since r9-1745

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Fixed for 11.5 as well.

[Bug c++/114572] [OpenMP] "internal compiler error: in assign_temp" with assignment operator and lastprivate clause

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Fixed for 11.5 as well.

[Bug tree-optimization/114566] [11 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #23 from Jakub Jelinek  ---
Fixed for 11.5 as well.

[Bug c++/114537] bit_cast does not work NSDMI of bitfields

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Fixed for 11.5 as well.

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 114537 Summary: bit_cast does not work NSDMI of bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114537

   What|Removed |Added

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

[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #18 from Jakub Jelinek  ---
Fixed for 11.5 as well.

[Bug c/114493] [11 Regression] internal compiler error: in fld_incomplete_type_of with may_alias

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #18 from Jakub Jelinek  ---
Fixed for 11.5 as well.

[Bug target/114310] [11 Regression] [aarch64] __sync_val_compare_and_swap fails on __int128_t with newval = 0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Fixed for 11.5 as well.