[Bug target/111313] RISC-V: Incorrect vsetvl code gen for 2 level loop

[pan2.li at intel dot com via Gcc-bugs]

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

Li Pan  changed:

   What|Removed |Added

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

--- Comment #2 from Li Pan  ---
Closed it as validated.

[Bug c/111317] New: RISC-V: Incorrect COST model for RVV conversions

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

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

Bug ID: 111317
   Summary: RISC-V: Incorrect COST model for RVV conversions
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

#include 

void foo (int32_t *__restrict a, int64_t * __restrict b, int n)
{
for (int i = 0; i < n; i++)
  b[i] = (int64_t)a[i];
}

--param=riscv-autovec-preference=scalable -O3 -fopt-info-vec-missed:
Failed to vectorize:

:5:23: missed: couldn't vectorize loop
:6:24: missed: not vectorized: no vectype for stmt: _4 = *_3;

However, try -fno-vect-cost-model.

We must adjust the COST model for RVV corretly.

[Bug target/111318] New: RISC-V: Redundant vsetvl instructions

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

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

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

The next two vsetvl instructions in assembly should be removed. Because the
vadd instruction is calculated in vlmax length, but where it is used only the
first avl, we can change the vl of the vadd to the avl of the instruction being
used.

C Code:
#include 

void foo1 (int32_t* restrict a, int32_t* restrict b, int32_t *restrict c, int
n)
{
for (int i = 0; i < n; i += 1)
  c[i] = a[i] + b[i];
}

Assembly Code:
foo1:
ble a3,zero,.L5
.L3:
vsetvli a5,a3,e32,m2,ta,ma
vle32.v v4,0(a0)
vle32.v v2,0(a1)
vsetvli a6,zero,e32,m2,ta,ma
sllia4,a5,2
vadd.vv v2,v2,v4
sub a3,a3,a5
vsetvli zero,a5,e32,m2,ta,ma
vse32.v v2,0(a2)
add a0,a0,a4
add a1,a1,a4
add a2,a2,a4
bne a3,zero,.L3
.L5:
ret

https://godbolt.org/z/jzWjK6EM9

[Bug c++/56289] Bad location for unused value warning with comma operator

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Gayathri Gottumukkala from comment #5)
> We cannot cast the two variables in single line using void.

That's not what the code is trying to do.

> Instead of that
> we have to use void for two variables separately.

Saying "if you don't write the code that triggers the bug, it doesn't trigger
the bug" is not very useful.

[Bug c/111319] New: Wrong code at -O2 on x86_64-linux-gnu

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 111319
   Summary: Wrong code at -O2 on x86_64-linux-gnu
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

The executable produced by gcc -O2 would crash. Not sure if there is UB in the
code or not as `h` has not been dereferenced after `h--`.

Compiler explorer: https://godbolt.org/z/avPze

$ cat a.c
int printf(const char *, ...);
int a, b = 5, c, d;
int e[2] = {0, 0};
int i() {
  int f = 0;
  int g[2] = {1, f};
  int *h = g;
  h--;
  if (!b)
while (h >= &c == 1)
  h--;
  h++;
  d = *h;
  return d;
}
int main() {
  if (e[i()])
e[0] = 0;
  printf("%d\n", a);
}
$
$ gcc -O2 a.c && ./a.out
Segmentation fault
$

[Bug c/111319] Wrong code at -O2 on x86_64-linux-gnu

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

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

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

  int *h = g;
  h--;

is undefined right away ...

[Bug target/111320] New: RISC-V: Failed combine extend + vfwredosum

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

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

Bug ID: 111320
   Summary: RISC-V: Failed combine extend + vfwredosum
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lehua.ding at rivai dot ai
  Target Milestone: ---

vfwcvt.f.f.v and vfredosum.vs should be combined to vfwredosum.vs


C Code:
#include 

double foo1 (float* restrict a, float* restrict b, int n)
{
double sum = 0;
for (int i = 0; i < n; i += 1)
  sum += a[i];
return sum;
}

Assembly Code:
foo1:
fmv.d.x fa0,zero
ble a2,zero,.L4
.L3:
vsetvli a5,a2,e64,m1,ta,ma
vle32.v v3,0(a0)
vfmv.s.fv2,fa0
sllia3,a5,2
vsetvli a4,zero,e32,mf2,ta,ma
sub a2,a2,a5
vfwcvt.f.f.vv1,v3
add a0,a0,a3
vsetvli zero,a5,e64,m1,ta,ma
vfredosum.vsv1,v1,v2
vfmv.f.sfa0,v1
bne a2,zero,.L3
ret
.L4:
ret


https://godbolt.org/z/dPesPnMWG

[Bug fortran/111321] New: Segmentation fault with associate construct

[alexandre.poux at coria dot fr via Gcc-bugs]

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

Bug ID: 111321
   Summary: Segmentation fault with associate construct
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexandre.poux at coria dot fr
  Target Milestone: ---

The following program triggers a segmentation fault when compiling

```fortran
program buggy
implicit none
double precision, dimension(1) :: array
integer :: i

associate (assoc => array)

assoc(1) = 1.5
assoc = assoc*2

end associate
contains

end program buggy
```

```
#> gfortran bug.f90
f951: internal compiler error: Segmentation fault
0x1a0e9c4 internal_error(char const*, ...)
???:0
0x77d375 gfc_expression_rank(gfc_expr*)
???:0
0x7392fc gfc_match_expr(gfc_expr**)
???:0
0x7397a8 gfc_match(char const*, ...)
???:0
0x739f59 gfc_match_assignment()
???:0
0x793a70 gfc_parse_file()
???:0
```

I'm using the latest version of gfortran from the archlinux repository
core/gcc-fortran 13.2.1-3

[Bug fortran/111321] Segmentation fault with associate construct

[alexandre.poux at coria dot fr via Gcc-bugs]

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

--- Comment #1 from Alexandre Poux  ---
Created attachment 55848
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55848&action=edit
a program triggering the segmentation fault

[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable

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

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

--- Comment #3 from JuzheZhong  ---
Confirm master GCC FAILs:

gcc FAILs: 166

FAIL: gcc.c-torture/execute/pr53645-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
FAIL: gcc.c-torture/execute/pr53645.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.vsetvl,  -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  comparison
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.vsetvl,  -O3 -g  comparison
FAIL: gcc.dg/analyzer/pr105252.c (test for excess errors)
FAIL: gcc.dg/analyzer/pr96713.c (internal compiler error: in
emit_move_multi_word, at expr.cc:4079)
FAIL: gcc.dg/analyzer/pr96713.c (test for excess errors)
FAIL: c-c++-common/opaque-vector.c  -Wc++-compat  (internal compiler error: in
emit_move_multi_word, at expr.cc:4079)
FAIL: c-c++-common/opaque-vector.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/pr105998.c  -Wc++-compat  (internal compiler error: in
emit_move_multi_word, at expr.cc:4079)
FAIL: c-c++-common/pr105998.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/scal-to-vec2.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/vector-compare-1.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/vector-compare-2.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/vector-scalar.c  -Wc++-compat  (internal compiler error: in
emit_move_multi_word, at expr.cc:4079)
FAIL: c-c++-common/vector-scalar.c  -Wc++-compat  (test for excess errors)
FAIL: gcc.dg/Wstrict-aliasing-bogus-ref-all-2.c (test for excess errors)
XPASS: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 72)
XPASS: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 77)
XPASS: gcc.dg/Wstringop-overflow-47.c pr97027 note (test for warnings, line 68)
FAIL: gcc.dg/Wstringop-overflow-70.c  (test for warnings, line 22)
FAIL: gcc.dg/pr100239.c (internal compiler error: in emit_move_multi_word, at
expr.cc:4079)
FAIL: gcc.dg/pr100239.c (test for excess errors)
FAIL: gcc.dg/pr100292.c (test for excess errors)
FAIL: gcc.dg/pr104992.c scan-tree-dump-times optimized " % " 9
FAIL: gcc.dg/pr105049.c (test for excess errors)
FAIL: gcc.dg/pr108805.c (test for excess errors)
FAIL: gcc.dg/pr34856.c (test for excess errors)
FAIL: gcc.dg/pr35442.c (test for excess errors)
FAIL: gcc.dg/pr53060.c (test for excess errors)
FAIL: gcc.dg/pr63914.c (test for excess errors)
FAIL: gcc.dg/pr70252.c (internal compiler error: in
gimple_expand_vec_cond_expr, at gimple-isel.cc:284)
FAIL: gcc.dg/pr70252.c (test for excess errors)
FAIL: gcc.dg/pr85430.c (test for excess errors)
FAIL: gcc.dg/pr85467.c (test for excess errors)
FAIL: gcc.dg/pr92301.c execution test
FAIL: gcc.dg/pr96453.c (test for excess errors)
FAIL: gcc.dg/pr96466.c (test for excess errors)
FAIL: gcc.dg/pr97238.c (internal compiler error: in emit_move_multi_word, at
expr.cc:4079)
FAIL: gcc.dg/pr97238.c (test for excess errors)
FAIL: gcc.dg/signbit-2.c scan-tree-dump-not optimized "\\s+>>\\s+31"
FAIL: gcc.dg/signbit-5.c execution test
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, doesn't
roll"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1"
FAIL: gcc.dg/var-expand1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
FAIL: gcc.dg/vshift-6.c (test for excess errors)
FAIL: gcc.dg/vshift-7.c (test for excess errors)
FAIL: gcc.dg/ipa/ipa-sra-19.c (test for excess errors)
FAIL: c-c++-common/torture/builtin-convertvector-2.c   -O0  (test for excess
errors)
FAIL: c-c++-common/torture/builtin-convertvector-2.c   -O1  (test for excess
errors)
FAIL: c-c++-common/torture/builtin-convertvector-2.c   -O2  (test for excess
errors)
FAIL: c-c++-common/torture/builtin-convertvector-2.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  (test for excess errors)
FAIL: c-c++-common/torture/builtin-convertvector-2.c   -O3 -g  (test for excess
errors)
FAIL: c-c++-common/torture/builtin-convertvector-2.c   -Os  (test for excess
errors)
FAIL: c-c++-common/torture/builtin-shufflevector-2.c   -O0  (internal compiler
error: in emit_move_multi_word, at expr.cc:4079)
FAIL: c-c++-common/torture/builtin-shufflevector-2.c   -O0  (test for excess
errors)
FAIL: c-c++-common/torture/builtin-shufflevector-2.c   -O1  (test for excess
errors)
FAIL: c-c++-common/torture/builtin-shufflevector-2.c   -O2  (test for excess
errors)
FAIL: c-c++-common/torture/builtin-shufflevector-2.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  (test for excess errors)
FAIL: c-c++-common/torture/builtin-shufflevector-2.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
FAIL: c-c++-common/torture/builtin-shufflevector-2.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: c-c++-

[Bug target/111252] LoongArch: Suboptimal code for (a & ~mask) | (b & mask) where mask is a constant with value ((1 << n) - 1) << m

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Xi Ruoyao :

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

commit r14-3773-g5b857e87201335148f23ec7134cf7fbf97c04c72
Author: Xi Ruoyao 
Date:   Tue Sep 5 19:42:30 2023 +0800

LoongArch: Use bstrins instruction for (a & ~mask) and (a & mask) | (b &
~mask) [PR111252]

If mask is a constant with value ((1 << N) - 1) << M we can perform this
optimization.

gcc/ChangeLog:

PR target/111252
* config/loongarch/loongarch-protos.h
(loongarch_pre_reload_split): Declare new function.
(loongarch_use_bstrins_for_ior_with_mask): Likewise.
* config/loongarch/loongarch.cc
(loongarch_pre_reload_split): Implement.
(loongarch_use_bstrins_for_ior_with_mask): Likewise.
* config/loongarch/predicates.md (ins_zero_bitmask_operand):
New predicate.
* config/loongarch/loongarch.md (bstrins__for_mask):
New define_insn_and_split.
(bstrins__for_ior_mask): Likewise.
(define_peephole2): Further optimize code sequence produced by
bstrins__for_ior_mask if possible.

gcc/testsuite/ChangeLog:

* g++.target/loongarch/bstrins-compile.C: New test.
* g++.target/loongarch/bstrins-run.C: New test.

[Bug c/111319] Wrong code at -O2 on x86_64-linux-gnu

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

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

--- Comment #2 from Andrew Pinski  ---
Also comparing unrelated addresses with >= is undefined.

[Bug c/111319] Wrong code at -O2 on x86_64-linux-gnu

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #3 from Xi Ruoyao  ---
Please try not to create more reports with "not sure if there is UB" esp. this
UB should be obvious, and it's also detectable with -fsanitize=undefined:

t.c:13:7: runtime error: load of address 0x7ffd53183020 with insufficient space
for an object of type 'int'
0x7ffd53183020: note: pointer points here
 2a 56 00 00  01 00 00 00 00 00 00 00  00 14 1a ed ca 50 d4 0e  00 00 00 00 00
00 00 00  98 31 18 53
  ^

[Bug target/111252] LoongArch: Suboptimal code for (a & ~mask) | (b & mask) where mask is a constant with value ((1 << n) - 1) << m

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Xi Ruoyao  ---
Done.

[Bug c/111319] Wrong code at -O2 on x86_64-linux-gnu

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #4 from Shaohua Li  ---
(In reply to Xi Ruoyao from comment #3)
> Please try not to create more reports with "not sure if there is UB" esp.
> this UB should be obvious, and it's also detectable with
> -fsanitize=undefined:
> 
> t.c:13:7: runtime error: load of address 0x7ffd53183020 with insufficient
> space for an object of type 'int'
> 0x7ffd53183020: note: pointer points here
>  2a 56 00 00  01 00 00 00 00 00 00 00  00 14 1a ed ca 50 d4 0e  00 00 00 00
> 00 00 00 00  98 31 18 53
>   ^

UBSan only detects it at -O2 level and I used `-O0
-fsanitize=address,undefined` to detect if there is any report.

https://godbolt.org/z/zvcG8znvT

[Bug libgcc/111322] New: non-canonical reference to canonical protected function `__pthread_key_create'

[judge.packham at gmail dot com via Gcc-bugs]

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

Bug ID: 111322
   Summary: non-canonical reference to canonical protected
function `__pthread_key_create'
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: judge.packham at gmail dot com
  Target Milestone: ---

Created attachment 55849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55849&action=edit
Exclude UCLIBC from GLIBC thread check

With binutils-2.40, uClibc-ng-1.0.43 and gcc-13.2.0 the following link error is
seen for some C++ code (ISL in this case).

ld.bfd: isl_test_cpp17.o: non-canonical reference to canonical protected
function `__pthread_key_create' in
x86_64-multilib-linux-uclibc/sysroot/lib64/libc.so.1
ld.bfd: failed to set dynamic section sizes: bad value

The problem appears to be that GCC uses the presence of __pthread_key_create()
to detect the use of pthreads with GNU libc but because uclibc-ng also defines
__GLIBC__ it ends up using the same symbol which for uclibc-ng is marked
protected. It looks as though the intended symbol should be pthread_cancel() as
for other libcs.

The attached patch is my attempt to resolve the issue.

[Bug libgcc/111322] non-canonical reference to canonical protected function `__pthread_key_create'

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

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

--- Comment #1 from Andrew Pinski  ---
uclibc should 100% not be defining __GLIBC__  at all ..

[Bug libgcc/111322] non-canonical reference to canonical protected function `__pthread_key_create'

[judge.packham at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Chris Packham  ---
I don't disagree but it appears to have been that way for some time. There are
other instances of the __GLIBC__ && !__UCLIBC__ in other corners

[Bug libstdc++/111323] New: [RISC_V] During Insmod "unknown relocation type 57" type in kernel space observed

[akhilesh.k at samsung dot com via Gcc-bugs]

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

Bug ID: 111323
   Summary: [RISC_V] During Insmod "unknown relocation type 57"
type in kernel space observed
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akhilesh.k at samsung dot com
  Target Milestone: ---

Hello 

with gcc 13.1 open source RISC-V Toolchain I observed "unknown relocation type
57" error message during insmod my kernel modules it seems this issue could
occurs in RISC-V when we  try to assemble or link a program, and the toolchain
encounters a relocation type that it doesn't recognize or support.

as per latest kernel 6.1 (which i am using code) doesn't support RELOC_NUMBER
(R_RISCV_32_PCREL, 57) . 


Here is my sample driver makefile 
=
CFLAGS +=-std=gnu11 #with this option getting "unknown relocation type 57"
obj-m := hello.o
hello-y := hello.o
all:
make  -C ${KDIR} M=$(PWD) modules
clean:
make  -C ${KDIR} M=$(PWD) clean


My dummy drive hello.c 



#include 
#include 

int init_module(void)  { printk(KERN_INFO "Hello
world.\n"); return 0; }

void cleanup_module(void)  { printk(KERN_INFO "Goodbye
world.\n"); }
 MODULE_LICENSE("GPL");

==


Using -std=gnu11 with gcc 13 generates R_RISCV_SET6 relocation in eh_frame
section which is not generated without -std=gnu11 flag even with same compiler
optimisations:

My insmod logs 
=
/bin # insmod hello.ko 
[   11.807337] hello: loading out-of-tree module taints kernel.
[   11.809680] hello: Unknown relocation type 57
insmod: can't insert 'hello.ko': invalid parameter

=




readelf output with -std=gnu11


Relocation section '.rela.eh_frame' at offset 0xb08 contains 10 entries:
  Offset  Info   Type   Sym. ValueSym. Name +
Addend
001c  001e0039 R_RISCV_32_PCREL   .L0  + 0
0020  001f0023 R_RISCV_ADD32 0022 .L0  + 0
0020  001e0027 R_RISCV_SUB32  .L0  + 0
0031  00200035 R_RISCV_SET6  001a .L0  + 0
0031  00210034 R_RISCV_SUB6  0008 .L0  + 0
0044  00220039 R_RISCV_32_PCREL  0022 .L0  + 0
0048  00230023 R_RISCV_ADD32 0042 .L0  + 0
0048  00220027 R_RISCV_SUB32 0022 .L0  + 0
0059  00240035 R_RISCV_SET6  003c .L0  + 0
0059  00250034 R_RISCV_SUB6  002a .L0  + 0

readelf output without -std=gnu11

Relocation section '.rela.text.unlikely' at offset 0x920 contains 6 entries:
  Offset  Info   Type   Sym. ValueSym. Name +
Addend
0008  00190017 R_RISCV_PCREL_HI2  .LC0 + 0
000c  001a0018 R_RISCV_PCREL_LO1 0008 .L0  + 0
0010  00200013 R_RISCV_CALL_PLT   _printk + 0
002a  001b0017 R_RISCV_PCREL_HI2 0010 .LC1 + 0
002e  001c0018 R_RISCV_PCREL_LO1 002a .L0  + 0
0032  00200013 R_RISCV_CALL_PLT   _printk + 


As a workaround i have two options either remove -std=gnu11 and use default
standards (-std=gnu17) or use KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
-fno-unwind-tables option 

but my query is why such relocations are generated with -std=gnu11

[Bug middle-end/111324] New: More optimization about "(X * Y) / Y"

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

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

Bug ID: 111324
   Summary: More optimization about "(X * Y) / Y"
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guojiufu at gcc dot gnu.org
  Target Milestone: ---

For case:
-- t.c
typedef unsigned int INT;

INT
foo (INT x, INT y)
{
  if (x > 100 || y > 100)
return 0;
  return (x * y) / y;
}
-
gcc -O2 t.c -S -fdump-tree-optimized

   [local count: 467721933]:
  _1 = x_3(D) * y_4(D);
  _5 = _1 / y_4(D);

   [local count: 1073741824]:
  # _2 = PHI <0(2), _5(4), 0(3)>
  return _2;

While for the below case, it can be optimized.

--
typedef unsigned int INT;

INT
foo (INT x, INT y)
{
  if (x > 100 || y > 100)
return 0;
  INT x1 = x + 1;
  INT y1 = y + 1;
  return (x1 * y1) / y1;
}
---

The "(x1 * y1) / y1" is optimized to "x1". 

   [local count: 467721933]:
  x1_4 = x_2(D) + 1;

   [local count: 1073741824]:
  # _1 = PHI <0(2), x1_4(4), 0(3)>
  return _1;

[Bug middle-end/111324] More optimization about "(X * Y) / Y"

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

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

--- Comment #1 from Jiu Fu Guo  ---
In match.pd, there is a pattern:

/* Simplify (t * 2) / 2) -> t.  */
(for div (trunc_div ceil_div floor_div round_div exact_div)
 (simplify
  (div (mult:c @0 @1) @1)
  (if (ANY_INTEGRAL_TYPE_P (type))
   (if (TYPE_OVERFLOW_UNDEFINED (type))
@0
#if GIMPLE
(with
 {
   bool overflowed = true;
   value_range vr0, vr1;
   if (INTEGRAL_TYPE_P (type)
   && get_global_range_query ()->range_of_expr (vr0, @0)
   && get_global_range_query ()->range_of_expr (vr1, @1)
   && !vr0.varying_p () && !vr0.undefined_p ()
   && !vr1.varying_p () && !vr1.undefined_p ())
 {

Here, "get_global_range_query" is able to get the value-range info for SSA.
But it does not handle the case t.c. "get_range_query" can handle it.

[Bug libgcc/111322] non-canonical reference to canonical protected function `__pthread_key_create'

[wbx at openadk dot org via Gcc-bugs]

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

Waldemar Brodkorb  changed:

   What|Removed |Added

 CC||wbx at openadk dot org

--- Comment #3 from Waldemar Brodkorb  ---
uClibc is doing this nearly since the beginning (commit
f91e94f6c5a1f1d6dfd3e5a535df303b805bf321 in 2001). I think normally this is
okay, because uClibc tries to be compatible to glibc. There are cornercases
like this issue. I think the patch is useful and should be applied.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

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

https://gcc.gnu.org/g:18c90eaa25363d34b5bef444fbbad04f5da2522d

commit r14-3774-g18c90eaa25363d34b5bef444fbbad04f5da2522d
Author: Jakub Jelinek 
Date:   Thu Sep 7 11:17:04 2023 +0200

middle-end: Avoid calling targetm.c.bitint_type_info inside of gcc_assert
[PR102989]

On Thu, Sep 07, 2023 at 10:36:02AM +0200, Thomas Schwinge wrote:
> Minor comment/question: are we doing away with the property that
> 'assert'-like "calls" must not have side effects?  Per 'gcc/system.h',
> this is "OK" for 'gcc_assert' for '#if ENABLE_ASSERT_CHECKING' or
> '#elif (GCC_VERSION >= 4005)' -- that is, GCC 4.5, which is always-true,
> thus the "offending" '#else' is never active.  However, it's different
> for standard 'assert' and 'gcc_checking_assert', so I'm not sure if
> that's a good property for 'gcc_assert' only?  For example, see also
>  "warn about asserts with side effects", or
> recent 
> "RFE: could -fanalyzer warn about assertions that have side effects?".

You're right, the
  #define gcc_assert(EXPR) ((void)(0 && (EXPR)))
fallback definition is incompatible with the way I've used it, so for
--disable-checking built by non-GCC it would not work properly.

2023-09-07  Jakub Jelinek  

PR c/102989
* expr.cc (expand_expr_real_1): Don't call
targetm.c.bitint_type_info
inside gcc_assert, as later code relies on it filling info
variable.
* gimple-fold.cc (clear_padding_bitint_needs_padding_p,
clear_padding_type): Likewise.
* varasm.cc (output_constant): Likewise.
* fold-const.cc (native_encode_int, native_interpret_int):
Likewise.
* stor-layout.cc (finish_bitfield_representative, layout_type):
Likewise.
* gimple-lower-bitint.cc (bitint_precision_kind): Likewise.

[Bug go/111310] BITINT_TYPE unsupported in godump.cc

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

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

--- Comment #3 from Jakub Jelinek  ---
Note, there is no guarantee that _BitInt(32) or _BitInt(64) are
passed/returned/laid out exactly like int32_t or int64_t (ditto for 8 and 16
bits), but on the current single target which supports them it is so far the
case.  _BitInt(128) has different alignment from __int128 though.

[Bug bootstrap/111325] New: config/acx.m4: _FOR_TARGET are not usable at top level

[pexu--- via Gcc-bugs]

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

Bug ID: 111325
   Summary: config/acx.m4: _FOR_TARGET are not usable at top
level
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p...@gcc-bugzilla.mail.kapsi.fi
  Target Milestone: ---

Hi.

`_FOR_TARGET' environment variables are not usable if used at top level
configure when build == host and build != target.

The problem is that ACX_CHECK_INSTALLED_TARGET_TOOL first checks for . 
If cache variable `ac_cv_path_' (`VAR'=`_FOR_TARGET') is empty,
attempts to use AC_PATH_PROG(VAR, PROG, ...) (defined at
lib/autoconf/programs.m4).  Unfortunately, AC_PATH_PROG always sets `' to
cache variable `ac_cv_path_' (that we know is potentially empty), i.e.
`_FOR_TARGET'=`ac_cv_path__FOR_TARGET'.  If  is not found,
the (empty) cache variable is not touched, thus overwriting any user provided
`_FOR_TARGET' value.

Then, NCN_STRICT_CHECK_TARGET_TOOLS tries to look for . 
If `_FOR_TARGET' should be used ( is not available),
it comes up now empty due to earlier AC_PATH_PROG call.

Ultimately, `_FOR_TARGET' is set to a default value 
for any subsequent configure runs and the user provided value is not picked up.
 This very likely will not work, given user attempted to override this using
`_FOR_TARGET'.

config/acx.m4:
340: AC_DEFUN([ACX_CHECK_INSTALLED_TARGET_TOOL], [
... # NB: Omitted when build == host and build != target.
359: if test -z "$ac_cv_path_$1" && test -n "$gcc_cv_tool_dirs"; then
360:   AC_PATH_PROG([$1], [$2], [], [$gcc_cv_tool_dirs]) # NB:
$1=$ac_cv_path_$1 if $1 is not found from $gcc_cv_tool_dirs.
361: fi
362: if test -z "$ac_cv_path_$1" ; then
363:   NCN_STRICT_CHECK_TARGET_TOOLS([$1], [$2])
364: else
365:   $1=$ac_cv_path_$1
366: fi
367: ]) []dnl # ACX_CHECK_INSTALLED_TARGET_TOOL

[Bug target/109773] RISC-V: ICE when build RVV Intrinsic in Both GCC 13 && GCC 14

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #3 from Kito Cheng  ---
Fixed on upstream for a while.

[Bug target/110560] internal compiler error: in extract_constrain_insn_cached, at recog.cc:2704

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #3 from Kito Cheng  ---
Should fixed now

[Bug libstdc++/111323] [RISC_V]with CFLAGS +=-std=gnu11 "unknown relocation type 57" observed during Insmod

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #1 from Xi Ruoyao  ---
You are misusing the kernel building system:

1. The kernel building system explicitly specifies -std=gnu11 so you don't need
to add it.  You should be able to see it via "make KDIR=... V=1".

2. "hello-y := hello.o" introduces a circular dependency.

3. The kernel building system suggests to use ccflags-y += ..., not CFLAGS +=
...

Read https://www.kernel.org/doc/html/latest/kbuild/modules.html.

Not a GCC issue anyway.

[Bug target/111074] RISC-V: segmentation fault during RTL pass: vsetvl

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #2 from Kito Cheng  ---
Fixed

[Bug target/111037] RISC-V: Invalid vsetvli fusion

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #3 from Kito Cheng  ---
Fixed

[Bug target/110299] RISC-V: ICE when build RVV intrinsic widen with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #2 from Kito Cheng  ---
Fixed on trunk

[Bug target/110277] RISC-V: ICE when build RVV intrinsic float reduction with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #3 from Kito Cheng  ---
Fixed on trunk

[Bug libstdc++/111315] libstdc++ stacktrace testsuite failures with --enable-default-pie

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #2 from Xi Ruoyao  ---
(In reply to Rimvydas (RJ) from comment #0)
> The GCC configured with --enable-default-pie gives:
> 
> === libstdc++ tests ===
> 
> Running target unix
> FAIL: 19_diagnostics/stacktrace/entry.cc execution test
> FAIL: 19_diagnostics/stacktrace/stacktrace.cc execution test
> 
> libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc:39: void
> test_members(): Assertion 'e1.source_line() == (__LINE__ - 5)' failed.
> libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc:132: void
> test_assign(): Assertion 's0.at(0).source_line() == (__LINE__ - 4)' failed.
> 
> In both cases source_line() methods return 0.
> 
> Also, the -fno-pie option cannot be used when linking these tescases:
> /usr/bin/ld: /tmp/ccv2BTff.o: relocation R_X86_64_32 against symbol
> `_ZNSt16stacktrace_entry14_S_err_handlerEPvPKci' can not be used when making
> a PIE object; recompile with -fPIE

You need to use both -no-pie and -fno-pie.  -fno-pie only tells the compiler
not to emit code for PIE, -no-pie tells the linker not to link the code for
PIE.

[Bug c++/107800] confusing message with to_address in C++17

[amatuladeeba at gmail dot com via Gcc-bugs]

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

Amatul Adeeba  changed:

   What|Removed |Added

 CC||amatuladeeba at gmail dot com

--- Comment #4 from Amatul Adeeba  ---
Tried the above typo mentioned, still not working.

[Bug libstdc++/111315] libstdc++ stacktrace testsuite failures with --enable-default-pie

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-09-07
 Status|UNCONFIRMED |NEW

--- Comment #3 from Xi Ruoyao  ---
Confirm the issue anyway, I saw it several times recently.

[Bug tree-optimization/111326] New: [14 Regression] Dead Code Elimination Regression since r14-376-g47a76439911

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

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

Bug ID: 111326
   Summary: [14 Regression] Dead Code Elimination Regression since
r14-376-g47a76439911
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/fv3szWMTE

Given the following code:

void foo(void);
static int a = 253, d, e, f, h, i, k;
static char j, m;
static short l, n;
static char(o)(char b, char c) { return b + c; }
void(p)(int);
short(q)(short);
static short(r)(int g) {
if (!(((g) >= 253) && ((g) <= 253))) {
__builtin_unreachable();
}
return 0;
}
static void s(char ab, short) {
int ac;
ab = 27;
for (; ab > 13; ab = ab - 9) {
j |= 10 | ac;
e = 0;
if (o(ab ^ a, d)) {
--l;
f = 0;
if (a)
;
else {
p(i);
k ^= q(0);
}
i = 5;
} else {
ac = 0;
for (; ac <= 38; ac = ac + 5) foo();
k = h &= 0 >= 0;
n = 0;
}
}
}
static unsigned t() {
s(m, a);
if (l)
;
else
r(3);
return f;
}
int main() {
d = a;
t();
r(a);
printf("", e, n);
}

gcc-trunk -O3 does not eliminate the call to foo:

main:
pushq   %rbp
movl$253, %edx
movl$27, %ebp
pushq   %rbx
subq$8, %rsp
movl$253, d(%rip)
.L5:
movl%ebp, %eax
orb $42, j(%rip)
movl$0, e(%rip)
xorl$-3, %eax
addb%dl, %al
je  .L6
subw$1, l(%rip)
movl$0, f(%rip)
movl$5, i(%rip)
.L3:
cmpb$18, %bpl
je  .L4
movld(%rip), %edx
movl$18, %ebp
jmp .L5
.p2align 4,,10
.p2align 3
.L4:
movswl  n(%rip), %edx
movle(%rip), %esi
movl$.LC0, %edi
xorl%eax, %eax
callprintf
addq$8, %rsp
xorl%eax, %eax
popq%rbx
popq%rbp
ret
.L6:
movl$8, %ebx
.L2:
callfoo
callfoo
subl$2, %ebx
jne .L2
movw$0, n(%rip)
movlh(%rip), %eax
andl$1, %eax
movl%eax, h(%rip)
movl%eax, k(%rip)
jmp .L3

gcc-13.2.0 -O3 eliminates the call to foo:

main:
subq$8, %rsp
movswl  n(%rip), %edx
xorl%esi, %esi
xorl%eax, %eax
movl$.LC0, %edi
orb $42, j(%rip)
subw$2, l(%rip)
movl$253, d(%rip)
movl$0, e(%rip)
movl$0, f(%rip)
movl$5, i(%rip)
callprintf
xorl%eax, %eax
addq$8, %rsp
ret

Bisects to r14-376-g47a76439911

[Bug libstdc++/108827] [C++23] Implement P2387R3, Pipe support for user-defined range adaptors

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

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

--- Comment #4 from Jonathan Wakely  ---
The new bind_back call wrapper still needs to be added (which will need to be
done before https://wg21.link/p2714r1 can be implemented for C++26).

[Bug c++/107800] confusing message with to_address in C++17

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

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

--- Comment #5 from Jonathan Wakely  ---
What is not working?

[Bug fortran/111321] Segmentation fault with associate construct

[kopper at iag dot uni-stuttgart.de via Gcc-bugs]

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

Patrick Kopper  changed:

   What|Removed |Added

 CC||kopper at iag dot 
uni-stuttgart.de

--- Comment #2 from Patrick Kopper  ---
Can reproduce both with the program by Alexandre and our own code base. Tested
with gfortran 13.1.1 (Arch), 13.2.1 (Arch) and 13.2.0 (Homebrew). gfortran
12.2.1 (Arch) confirmed to compile without error or warnings.

```
#> gfortran bug.f90
f951: internal compiler error: Segmentation fault: 11
#> gfortran --version
GNU Fortran (Homebrew GCC 13.2.0) 13.2.0
```

[Bug libstdc++/111327] New: std::bind_front doesn't perfectly forward according to value category of the call wrapper object

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

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

Bug ID: 111327
   Summary: std::bind_front doesn't perfectly forward according to
value category of the call wrapper object
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

Testcase:

#include 

struct F {
  void operator()() & = delete; // #1
  void operator()() const &;// #2
};

int main() {
  auto f = F{};
  auto g = std::bind_front(F{});
  f(); // error: use of deleted function
  g(); // incorrectly calls #2 instead of being ill-formed
}

Since f isn't invocable as a non-const lvalue, g shouldn't be either.

[Bug tree-optimization/111326] [14 Regression] Dead Code Elimination Regression since r14-376-g47a76439911

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/111225] ICE in curr_insn_transform, unable to generate reloads for xor, since r14-2447-g13c556d6ae84be

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Vladimir Makarov :

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

commit r14-3783-gf7bca44d97ad01b39f9d6e7809df7bf517eeb2fb
Author: Vladimir N. Makarov 
Date:   Thu Sep 7 09:59:10 2023 -0400

[LRA]: Don't reuse chosen insn alternative with special memory constraint

To speed up GCC, LRA reuses chosen alternative from previous
constraint subpass.  A spilled pseudo is considered ok for any memory
constraint although stack slot assigned to the pseudo later might not
satisfy the chosen alternative constraint.  As we don't consider all insn
alternatives on the subsequent LRA sub-passes, it might result in LRA
failure
to generate the correct insn.  This patch solves the problem.

gcc/ChangeLog:

PR target/111225
* lra-constraints.cc (goal_reuse_alt_p): New global flag.
(process_alt_operands): Set up the flag.  Clear flag for chosen
alternative with special memory constraints.
(process_alt_operands): Set up used insn alternative depending on
the flag.

gcc/testsuite/ChangeLog:

PR target/111225
* gcc.target/i386/pr111225.c: New test.

[Bug target/95751] [aarch64] Consider using ldapr for __atomic_load_n(acquire) on ARMv8.3-RCPC

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

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |13.0

--- Comment #2 from Wilco  ---
Fixed in GCC13.

[Bug middle-end/110773] [Aarch64] crash (SIGBUS) due to atomic instructions on under-aligned memory

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

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #2 from Wilco  ---
This is really a user error, not a compiler issue. Just write it like:

struct Storage {
std::atomic fp1;
float padding;
std::atomic fp2;
} storage;

This ensures the correct alignment required for atomic accesses of fp1/fp2.

[Bug target/111263] test case gfortran.dg/ieee/comparisons_3.F90 fails

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

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

--- Comment #2 from seurer at gcc dot gnu.org ---
No, that is not failing.

[Bug c/111328] New: ICE: verify_flow_info failed since r14-3459-g0c78240fd7d

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 111328
   Summary: ICE: verify_flow_info failed since
r14-3459-g0c78240fd7d
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: jh at suse dot cz
  Target Milestone: ---

gcc at -O3 crashes on the following testcase.

Bisected to r14-3459-g0c78240fd7d

Compiler explorer: https://godbolt.org/z/G3rPdq6db


$ cat a.c
int a, b, c, d;
short e;
int f(g, h) { return h == 0 || g == 83647 && h == 1 ?: g / h; }
char *i(char *g) {
  if (a)
do
  if (*g++ == 0)
return 0;
while (a);
  return g;
}
int j() {
  char k = 0, l = *i(&k) = l;
  for (; b; b++) {
c = 1;
for (; d + c >= 0; c--)
  ;
  }
  for (;;)
if (f(e))
  break;
}
int main() {}
$ gcc -O2 a.c
: In function 'f':
:3:5: warning: type of 'g' defaults to 'int' [-Wimplicit-int]
3 | int f(g, h) { return h == 0 || g == 83647 && h == 1 ?: g / h; }
  | ^
:3:5: warning: type of 'h' defaults to 'int' [-Wimplicit-int]
: In function 'j':
:12:5: error: count of bb 32 not initialized
   12 | int j() {
  | ^
:12:5: error: count of bb 33 not initialized
:12:5: error: count of bb 34 not initialized
:12:5: error: count of bb 35 not initialized
:12:5: error: count of bb 37 not initialized
during GIMPLE pass: vect
:12:5: internal compiler error: verify_flow_info failed
0x21d80ae internal_error(char const*, ...)
???:0
0xb8c64f verify_flow_info()
???:0
0x112933f cleanup_tree_cfg(unsigned int)
???:0
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.
Compiler returned: 1
$

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||alexandre.poux at coria dot fr

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

[Bug fortran/111321] Segmentation fault with associate construct

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Duplicate.

Fixed in 13.3.

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

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|13.2|13.3

--- Comment #23 from anlauf at gcc dot gnu.org ---
The fix was applied to 13-branch after the 13.2 release.
Updating target milestone appropriately.

[Bug libgomp/111044] [OpenMP] Use additional kinds of libmemkind for allocators; make libgomp.texi doc more explicit

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

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

--- Comment #1 from Tobias Burnus  ---
Additionally: OpenMP states for omp_init_allocator:

"if an allocator based on the requirements cannot be created then the special
omp_null_allocator handle is returned."

libgomp's routine currently only returns omp_null_allocator if either an
invalid value has been used for the memory space / trait key / trait value - or
when pinned memory has been requested (as it is not yet implemented).

I think that's fine - but needs to be better documented. This applies to the
predefined allocators and to those created by OMP_ALLOCATOR,
omp_init_allocator, and by the 'using_allocators' directive (all using
internally omp_init_allocator).

[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp

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

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

--- Comment #12 from sandra at gcc dot gnu.org ---
Improved and tested patch posted here:

https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629616.html

IIUC the temporaries introduced in non-full-expressions are bound in a block
that encloses the entire full-expression.  The restructuring that moves
intervening code into the loop body operates on whole statements, not
subexpressions, so I convinced myself there should be nothing to do here.

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

--- Comment #14 from François Dumont  ---
Good news then.

On my side I only had some failures due to a faulty friend declaration in
gnu-versioned-namespace mode in  for which I've submitted a patch:
https://gcc.gnu.org/pipermail/libstdc++/2023-August/056560.html

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

--- Comment #15 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Iain Sandoe from comment #12)
> > (In reply to Iain Sandoe from comment #11)
> > > (In reply to François Dumont from comment #10)
> > > > This is because you are facing the PR65762 issue. I just attached a path
> > > > proposal to it that you need to apply too to be able to run your test.
> > > > You'll be even able to simply use --disable-libstdcxx-dual-abi cause I 
> > > > made
> > > > cxx11 abi the default in this case.

> It looks like this was a merge artefact, which I resolved and now it builds
> - I have some testsuite fails to examine.

With both patches applied (on top of trunk from yesterday) on both Linux and
Darwin I am seeing regressions in the C++ and libstdc++ test suites.  For the
darwin case, I could perhaps have another merge error - but the Linux case has
only your two patches and configured with
--enable-symvers=gnu-versioned-namespace (only).

---

many of the libstdc++ fails are of this form:

/home/iains/gcc-master/bld-patched/x86_64-pc-linux-gnu/32/libstdc++-v3/include/format:3519:
error: 'std::__format::_Arg_store<_Context, _Args>::_Arg_store(_Tp& ...) [with
_Tp = {const std::chrono::time_point > >}; _Context =
std::basic_format_context, char>; _Args =
{std::basic_format_arg,
char> >::handle}]' is private within this context

many of the c++ fails are of this form:

contracts-tmpl-spec1.C:(.text+0x6f): undefined reference to
`handle_contract_violation(std::experimental::contract_violation const&)'

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

--- Comment #16 from Iain Sandoe  ---
(In reply to François Dumont from comment #14)
> Good news then.
> 
> On my side I only had some failures due to a faulty friend declaration in
> gnu-versioned-namespace mode in  for which I've submitted a patch:
> https://gcc.gnu.org/pipermail/libstdc++/2023-August/056560.html

Ah so probably that covers most of the libstdc++ cases - they do seem to be
format-related.

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

--- Comment #17 from François Dumont  ---
(In reply to Iain Sandoe from comment #15)
> 
> many of the c++ fails are of this form:
> 
> contracts-tmpl-spec1.C:(.text+0x6f): undefined reference to
> `handle_contract_violation(std::experimental::contract_violation const&)'

I'm surprised that my patch can have an impact on the C++ front end but I'll
give it a try. Did you first run those without my patches ?

I've never run the C++ tests. They can be run without a proper libstdc++ build,
no ?

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

--- Comment #18 from Iain Sandoe  ---
for changes to libstdc++ or the FE I usually run "make check-c++" which does
the library (plus the libgomp and itm deps) and the FE.

My guess is that the FE is referencing something that needs to have an inline
namespace added.

There are also some failing coroutine tests (because their scan strings need to
account for the inline namespace - I have a WIP patch for that, it's just
tedious editing of pattern matches).

[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Sandra Loosemore :

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

commit r14-3791-gab4bdad49716eb1c60e22e0e617d5eb56b0bac6f
Author: Sandra Loosemore 
Date:   Thu Sep 7 16:12:20 2023 +

OpenMP: Fix ICE in fixup_blocks_walker [PR111274]

This ICE was caused by an invalid assumption that all BIND_EXPRs have
a non-null BIND_EXPR_BLOCK.  In C++ these do exist and are used for
temporaries introduced in expressions that are not full-expressions.
Since they have no block to fix up, the traversal can just ignore
these tree nodes.

gcc/cp/ChangeLog
PR c++/111274
* parser.cc (fixup_blocks_walker): Check for null BIND_EXPR_BLOCK.

gcc/testsuite/ChangeLog
PR c++/111274
* g++.dg/gomp/pr111274.C: New test case.

[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from sandra at gcc dot gnu.org ---
Should be fixed now.

[Bug other/111329] New: [14 regression] gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c fails after r14-3745-g4f4fa2501186e4

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

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

Bug ID: 111329
   Summary: [14 regression]
gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c fails
after r14-3745-g4f4fa2501186e4
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:4f4fa2501186e43d115238ae938b3df322c9e02a, r14-3745-g4f4fa2501186e4
make  -k check-gcc
RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c"
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c expected multiline
pattern lines 17-39
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c 2 blank line(s) in output
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c (test for excess errors)
# of expected passes2
# of unexpected failures3

commit 4f4fa2501186e43d115238ae938b3df322c9e02a (HEAD, refs/bisect/bad)
Author: Jakub Jelinek 
Date:   Wed Sep 6 17:25:49 2023 +0200

Middle-end _BitInt support [PR102989]

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

--- Comment #19 from Iain Sandoe  ---
(In reply to François Dumont from comment #17)
> (In reply to Iain Sandoe from comment #15)

Your proposed patch for the friend issue does fix the libstdc++ cases for my
Darwin patchset.

> > many of the c++ fails are of this form:
> > 
> > contracts-tmpl-spec1.C:(.text+0x6f): undefined reference to
> > `handle_contract_violation(std::experimental::contract_violation const&)'
> 
> I'm surprised that my patch can have an impact on the C++ front end but I'll
> give it a try. 

I do not think it's affecting the FE as such - but rather that some of the
tests include stdc++ headers (I try to avoid it in the testsuite, but obviously
things like coroutines cannot avoid it)

[Bug other/111329] [14 regression] gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c fails after r14-3745-g4f4fa2501186e4

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I don't think that is a correct bi-section, I don't think my patch has anything
to do with that.
I see zero difference in the output between r14-3744 and r14-3745, in fact I
don't see any difference in output between r14-2029 (when these options were
introduced) and latest trunk.
But the test includes , perhaps that header changed?

[Bug c++/111226] constexpr doesn't detect change of union to empty member

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

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

Patrick Palka  changed:

   What|Removed |Added

   Keywords||accepts-invalid,
   ||rejects-valid
 Status|UNCONFIRMED |NEW
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-09-07

--- Comment #1 from Patrick Palka  ---
Confirmed.

[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|NEW |WAITING

--- Comment #12 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14.

Shall we close it?  Or does it deserve backporting?

[Bug analyzer/111329] [14 regression] gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c fails after r14-3745-g4f4fa2501186e4

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

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

--- Comment #2 from David Malcolm  ---
Possibly another duplicate of bug 110483.

[Bug tree-optimization/111328] ICE: verify_flow_info failed since r14-3459-g0c78240fd7d

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
  Component|c   |tree-optimization
   Keywords||ice-checking,
   ||ice-on-valid-code

[Bug middle-end/111324] More optimization about "(X * Y) / Y"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed||2023-09-07
   Severity|normal  |enhancement
 CC||pinskia at gcc dot gnu.org

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

So using the local range in this case is ok. There might be only a few times we
don't want to use it though in match.

Here is a testcase where we should just change it into "return x;" but don't
yet:
```
typedef unsigned int INT;

INT
foo (INT x, INT y)
{
  if (x > 100 || y > 100)
return x;
  return (x * y) / y;
}
```

Note clang is able to change it though.

[Bug tree-optimization/110875] [14 Regression] Dead Code Elimination Regression since r14-2501-g285c9d042e9

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r14-3792-gcf2ae3fff4ee9bf884b122ee6cd83bffd791a16f
Author: Andrew MacLeod 
Date:   Thu Sep 7 11:15:50 2023 -0400

Some ssa-names get incorrectly marked as always_current.

When range_of_stmt invokes prefill_name to evaluate unvisited dependencies
it should not mark already visited names as always_current.

PR tree-optimization/110875
gcc/
* gimple-range.cc (gimple_ranger::prefill_name): Only invoke
cache-prefilling routine when the ssa-name has no global value.

gcc/testsuite/
* gcc.dg/pr110875.c: New.

[Bug analyzer/111329] [14 regression] gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c fails after r14-3745-g4f4fa2501186e4

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

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

--- Comment #3 from seurer at gcc dot gnu.org ---
It is the one that appears to trigger this failure, though.  And as for being a
duplicate of that other one I see this on both powerpc64 BE and LE.

git bisect log

git bisect start
# good: [1b4c70d4271a00514ae20970d483c3b78d9d66ef] RISC-V: Fix VSETVL PASS
AVL/VL fetch bug[111295]
git bisect good 1b4c70d4271a00514ae20970d483c3b78d9d66ef
# bad: [52e270e847d240fb68a27c88ee60189515a6] Additional _BitInt test
coverage [PR102989]
git bisect bad 52e270e847d240fb68a27c88ee60189515a6
# bad: [8c984a1c3693df63520558631c827bb2c2d8b5bc] C _BitInt support [PR102989]
git bisect bad 8c984a1c3693df63520558631c827bb2c2d8b5bc
# bad: [b38deff6127778fed453bb647e32738ba5c78e33] i386: Enable _BitInt on
x86-64 [PR102989]
git bisect bad b38deff6127778fed453bb647e32738ba5c78e33
# bad: [4f4fa2501186e43d115238ae938b3df322c9e02a] Middle-end _BitInt support
[PR102989]
git bisect bad 4f4fa2501186e43d115238ae938b3df322c9e02a
# good: [6b96de22d6bcadb45530c1898b264e4738afa4fd] RISC-V: Fix incorrect mode
tieable which cause ICE in RA[PR111296]
git bisect good 6b96de22d6bcadb45530c1898b264e4738afa4fd
# first bad commit: [4f4fa2501186e43d115238ae938b3df322c9e02a] Middle-end
_BitInt support [PR102989]


g:6b96de22d6bcadb45530c1898b264e4738afa4fd, r14-3744-g6b96de22d6bcad
make  -k check-gcc
RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c"
# of expected passes4


g:4f4fa2501186e43d115238ae938b3df322c9e02a, r14-3745-g4f4fa2501186e4
make  -k check-gcc
RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c"
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c expected multiline
pattern lines 17-39
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c 2 blank line(s) in output
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c (test for excess errors)
# of expected passes2
# of unexpected failures3

[Bug tree-optimization/110875] [14 Regression] Dead Code Elimination Regression since r14-2501-g285c9d042e9

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Andrew Macleod  ---
When range_of_stmt invokes prefill_name to evaluate unvisited dependencies it
should not mark visited names as always_current.

when ranger_cache::get_globaL_range() is invoked with the optional  "current_p"
flag, it triggers additional functionality. This call is meant to be from
within ranger and it is understood that if the current value is not current, 
set_global_range will always be called later with a value.  Thus it sets the
always_current flag in the temporal cache to avoid computation cycles.

the prefill_stmt_dependencies () mechanism within ranger is intended to emulate
the bahaviour of range_of_stmt on an arbitrarily long series of unresolved
dependencies without triggering the overhead of huge call chains from the
range_of_expr/range_on_entry/range_on_exit routines.  Rather, it creates a
stack of unvisited names, and invokes range_of_stmt on them directly in order
to get initial cache values for each ssa-name.

The issue in this PR was that routine was incorrectly invoking the
get_global_cache to determine whether there was a global value.  If there was,
it would move on to the next dependency without invoking set_global_range to
clear the always_current flag.

What it should have been doing was simply checking if there as a global value,
and if there was not, add the name for processing and THEN invoke
get_global_value to do all the special processing.
fixed.

[Bug analyzer/111329] [14 regression] gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c fails after r14-3745-g4f4fa2501186e4

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Ah, actually that patch changed the definition of pp_wide_int macro
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/pretty-print.h;h=6eb99b1f6901e4367687081dcd21298719ccdc40;hp=369be6e7ba767bfbf2ccf74d5e602371279726f4;hb=4f4fa2501186e4;hpb=6b96de22d6bcadb45530c1898b264e4738afa4fd
because with the larger precision wide_int the fixed size buffer isn't enough.
Now, in the analyzer case, seems it is used with a function call
  pp_wide_int (pp, get_last_byte_offset (), SIGNED);
and perhaps the const wide_int_ref in that case binds to a temporary which goes
out of scope at the end of the statement.
So, if we want to support such usages, wonder if I don't need to rewrite
pp_wide_int macro into an inline function and perhaps use there an out of line
function for the larger precision case (because XALLOCAVEC will cause inlining
to fail).

[Bug modula2/111330] New: [13 Regression] Bootstrap failure building SeqFile.lo

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

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

Bug ID: 111330
   Summary: [13 Regression] Bootstrap failure building SeqFile.lo
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I've done a successful Fedora distro build of GCC 13
r13-7622-g3e9aaa9bcb2fc64e64
based snapshot and that and all earlier ones went fine, but when trying to
build
a r13-7778-g78f63dd9fa9ff29949 based snapshot, I'm seeing weird Modula 2
failures.
See https://kojipkgs.fedoraproject.org//work/tasks/4565/105824565/build.log
or https://kojipkgs.fedoraproject.org//work/tasks/4525/105824525/build.log
etc., it is all arches.  What I see in the logs is:
/bin/sh ../libtool --tag=CC   --mode=compile
/builddir/build/BUILD/gcc-13.2.1-20230906/obj-x86_64-redhat-linux/./gcc/gm2
-B/builddir/build/BUILD/gcc-13.2.1-20230906/obj-x86_64-redhat-linux/./gcc/ -c
-O2 -fexceptions -g -grecord-gcc-switches -Wall -Wformat-security
-Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -O2 -fexceptions -g
-grecord-gcc-switches -Wall -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -fm2-pathname=m2iso -I. -Ilibm2iso
-I/builddir/build/BUILD/gcc-13.2.1-20230906/gcc/m2/gm2-libs-iso
-fm2-pathname=m2pim -I/builddir/build/BUILD/gcc-13.2.1-20230906/gcc/m2/gm2-libs
-fiso -fextended-opaque -fm2-g -g -Wreturn-type -fcase -fm2-prefix=m2iso
../../../../libgm2/libm2iso/../../gcc/m2/gm2-libs-iso/SeqFile.mod -o SeqFile.lo
libtool: compile: 
/builddir/build/BUILD/gcc-13.2.1-20230906/obj-x86_64-redhat-linux/./gcc/gm2
-B/builddir/build/BUILD/gcc-13.2.1-20230906/obj-x86_64-redhat-linux/./gcc/ -c
-O2 -fexceptions -g -grecord-gcc-switches -Wall -Wformat-security
-Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -O2 -fexceptions -g
-grecord-gcc-switches -Wall -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -fm2-pathname=m2iso -I. -Ilibm2iso
-I/builddir/build/BUILD/gcc-13.2.1-20230906/gcc/m2/gm2-libs-iso
-fm2-pathname=m2pim -I/builddir/build/BUILD/gcc-13.2.1-20230906/gcc/m2/gm2-libs
-fiso -fextended-opaque -fm2-g -g -Wreturn-type -fcase -fm2-prefix=m2iso
../../../../libgm2/libm2iso/../../gcc/m2/gm2-libs-iso/SeqFile.mod  -fPIC -DPIC
-o .libs/SeqFile.o
../../gcc/m2/gm2-compiler/M2SymInit.def:1:case statement has no matching
selection
make[5]: *** [Makefile:912: SeqFile.lo] Error 1

Now, I have no idea if this case statement has no matching selection message is
an error or not and if it is, if it is what caused SeqFile.lo to fail building.

I've reproduced it in a local Fedora mock, but when I do make -j32 in the
libgm2 build directory afterwards, everything including SeqFile.lo builds fine,
so I wonder if it isn't another case of missing Makefile dependencies or
something similar.

Any ideas (including ideas what I could try to understand what's going on)?

[Bug fortran/108957] Fortran FE memleak with interfaces

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Mikael,

are you still onto it?

[Bug c/111331] New: Wrong code at -O1 on x86_64-linux-gnu since

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 111331
   Summary: Wrong code at -O1 on x86_64-linux-gnu since
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

gcc at -O1 produced the wrong code.

Bisected to r9-3606-g1cab645d3e3

Compiler explorer: https://godbolt.org/z/5YEv44PTa

$ cat a.c
int printf(const char *, ...);
int a;
int b;
int c(int d, int e, int f) {
  if (d < e)
return e;
  if (d > f)
return f;
  return d;
}
int main() {
  int g = -1;
  a = c(b + 30, 29, g + 29);
  printf("%d\n", a);
}
$
$ gcc -O0 a.c && ./a.out
28
$ gcc -O1 a.c && ./a.out
29
$

[Bug tree-optimization/111331] Wrong code at -O1 on x86_64-linux-gnu since

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2023-09-07
   Target Milestone|--- |11.5
  Known to work||5.1.0
   Keywords||needs-bisection, wrong-code
  Known to fail||6.1.0
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed, note that patch just exposed a latent bug. Here is a testcase which
shows the failure even in GCC 6 but works in GCC 5:
```

int a;
int b;
int c(int d, int e, int f) {
  if (d < e)
return e;
  return (d > f) ? f : d;
}
int main() {
  int g = -1;
  a = c(b + 30, 29, g + 29);
  volatile int t = a;
  if (a != 28)
__builtin_trap();
}
```

[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow

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

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

--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Kees Cook from comment #11)
> The trouble with "optimize" is that it just doesn't work. The kernel has
> banned its use because it results in all other optimization options being
> forgotten for the function in question.

How about Jacub's another suggestion in comment#10:

"If you don't want to use optimize attribute, there is always the option to
just do the arithmetics in unsigned types in the few selected functions where
you don't want the sanitization"?

is it possible to use "unsigned" integer instead of "signed" integer for the
cases you want the "wrap around" behavior when overflow? 

if not, what's the major issue with this workaround?

[Bug analyzer/110830] -Wanalyzer-use-of-uninitialized-value false negative due to use-after-free::supercedes_p.

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Benjamin Priour :

https://gcc.gnu.org/g:7d2274b9e346f44f8f6598b9dbb9fa95259274a2

commit r14-3794-g7d2274b9e346f44f8f6598b9dbb9fa95259274a2
Author: benjamin priour 
Date:   Fri Sep 1 20:21:41 2023 +0200

analyzer: Call off a superseding when diagnostics are unrelated [PR110830]

Before this patch, a saved_diagnostic would supersede another at
the same statement if and only its vfunc supercedes_p returned true
for the other diagnostic's kind.
That both warning were unrelated - i.e. resolving one would not fix
the other - was not considered in making the above choice.

This patch makes it so that two saved_diagnostics taking a different
outcome of at least one common conditional branching cannot supersede
each other.

Signed-off-by: Benjamin Priour 
Co-authored-by: David Malcolm 
Signed-off-by: David Malcolm 

gcc/analyzer/ChangeLog:

PR analyzer/110830
* diagnostic-manager.cc
(compatible_epaths_p): New function.
(saved_diagnostic::supercedes_p): Now calls the above
to determine if the diagnostics do overlap and the superseding
may proceed.

gcc/testsuite/ChangeLog:

PR analyzer/110830
* c-c++-common/analyzer/pr110830.c: New test.

[Bug tree-optimization/111331] Wrong code at -O1 on x86_64-linux-gnu since

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

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

--- Comment #2 from Andrew Pinski  ---
For the trunk:
```
phiopt match-simplify trying:
_3 > 28 ? _9 : 29
Applying pattern match.pd:5446, gimple-match-3.cc:3125

phiopt match-simplify back:
_5 = MAX_EXPR <_9, 29>;
result: _5
accepted the phiopt match-simplify.
statement un-sinked:
_9 = MIN_EXPR <_3, 28>;
```
IR before the first phiopt:
```
  if (_3 <= 28)
goto ; [34.00%]
  else
goto ; [66.00%]

   :
  _9 = MIN_EXPR <_3, 28>;

   :
  # _14 = PHI <29(2), _9(3)>
```
There is a mix match between the 29 and the 28 here ...

[Bug tree-optimization/111331] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu since

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

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

--- Comment #3 from Andrew Pinski  ---
For the trunk the problem is in match (and phiopt)
Match pattern:
/* Optimize (a CMP CST1) ? max : a */



r6-7425-ga9fee7cdc3c62d0e51730b6a9814909c557d3070 most likely introduced it for
GCC 6.

For the trunk the issue is also dealing with minmax_from_comparison .

[Bug tree-optimization/111331] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu since

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

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

--- Comment #4 from Andrew Pinski  ---
Reduced testcase:
```
int a;
int b;

int main() {
  int d = b+30;
  {
int t;
if (d < 29)
  t =  29;
else
  t = (d > 28) ? 28 : d;
a = t;
  }
  volatile int t = a;
  if (a != 28)
__builtin_trap();
}
```

[Bug tree-optimization/111331] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu since

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||14.0

--- Comment #5 from Andrew Pinski  ---
here is a testcase that fails even at -O0 on the trunk due to the match
patches:
```
int a;
int b;

int main() {
  int d = b+30;
  {
int t;
t = d < 29 ? 29 : ((d > 28) ? 28 : d);
a = t;
  }
  volatile int t = a;
  if (a != 28)
__builtin_trap();
}
```

[Bug analyzer/110529] Analyzer fails to handle computed goto

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

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

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

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

commit r14-3796-g1b761fede44afac5fa72e77caced9beda93fb381
Author: David Malcolm 
Date:   Thu Sep 7 18:43:05 2023 -0400

analyzer: basic support for computed gotos (PR analyzer/110529)

PR analyzer/110529 notes that -fanalyzer was giving up on execution
paths that follow a computed goto, due to ignoring CFG edges with the
flag EDGE_ABNORMAL set.

This patch implements enough handling for them to allow analysis of
such execution paths to continue.

gcc/analyzer/ChangeLog:
PR analyzer/110529
* program-point.cc (program_point::on_edge): Don't reject
EDGE_ABNORMAL for computed gotos.
* region-model.cc (region_model::maybe_update_for_edge): Handle
computed goto statements.
(region_model::apply_constraints_for_ggoto): New.
* region-model.h (region_model::apply_constraints_for_ggoto): New
decl.
* supergraph.cc (supernode::get_label): New.
* supergraph.h (supernode::get_label): New decl.

gcc/testsuite/ChangeLog:
PR analyzer/110529
* c-c++-common/analyzer/computed-goto-1.c: New test.
* gcc.dg/analyzer/computed-goto-pr110529.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/110529] Analyzer fails to handle computed goto

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from David Malcolm  ---
Should be fixed on trunk for gcc 14 by the above commit.

[Bug tree-optimization/111148] Missing boolean optimizations due to comparisons

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

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

--- Comment #2 from Andrew Pinski  ---
The one which I had missed:

_Bool f(int x, int y, int w, int z)
{
  _Bool a = z == w;
  _Bool b = x == y;
  return (a & !b) | (a ^ b); // a ^ b
}

[Bug tree-optimization/111331] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu since

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
I am going to fix this.

[Bug tree-optimization/111331] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu since

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #7 from Andrew Pinski  ---
Fix for the trunk -O0 issue:
```
diff --git a/gcc/match.pd b/gcc/match.pd
index 8c24dae71cd..f67bb9c12e7 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -5435,6 +5435,16 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(with
 {
   tree_code code = minmax_from_comparison (cmp, @0, @1, @0, @4);
+  /* For LT and GT, @4 and @1 needs to be the same.\
+For an example:
+ _3 > 28 ? MIN_EXPR <_3, 28> : 29
+is not the same as
+ MAX_EXPR , 29>
+But `_3 >= 28` would be. */
+  if (cmp != LE_EXPR
+  && cmp != GE_EXPR
+  && !operand_equal_p (@1, @4))
+code = ERROR_MARK;
 }
 (if ((cmp == LT_EXPR || cmp == LE_EXPR)
 && code == MIN_EXPR
```

But we still fail the original testcase at -O1 because the code in phiopt is
still needs to be fixed ...

[Bug target/111332] New: Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

[d_vampile at 163 dot com via Gcc-bugs]

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

Bug ID: 111332
   Summary: Using GCC7.3.0 and GCC10.3.0 to compile the same test
case, assembler file instructions are different and
performance fallback is obvious.
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d_vampile at 163 dot com
  Target Milestone: ---

Created attachment 55850
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55850&action=edit
test case

Created Attachment

Test platform: x86_64

Compiler Options:  
gcc main.c -g -o main -O2 -msse4.2 -mavx2 -fno-inline

Runtime with gcc7.3.0:
$ time ./main_gcc7.3 2000
start to run 2000.
end to run 2000.

real6m30.461s
user6m26.587s
sys 0m0.814s


Runtime with gcc10.3.0:
$ time ./main_gcc10.3 2000
start to run 2000.
end to run 2000.

real7m18.696s
user7m13.912s
sys 0m1.098s

Programs compiled with gcc10.3.0 run significantly longer than gcc7.3.0

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

[d_vampile at 163 dot com via Gcc-bugs]

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

d_vampile  changed:

   What|Removed |Added

 CC||d_vampile at 163 dot com

--- Comment #1 from d_vampile  ---
Created attachment 55851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55851&action=edit
Assembly Instruction Differences

This figure shows the assembly instructions. The left one is gcc7.3.0, and the
right one is gcc10.3.0.

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

[d_vampile at 163 dot com via Gcc-bugs]

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

--- Comment #2 from d_vampile  ---
gcc7.3.0 program use vmovups and vmovups instructions , but gcc10.3.0 program
only use vmovups instructions.In addition, the order of the two assembly
instructions is not consistent.

[Bug target/111333] New: Runtime failure for fcmulcph instrinsic

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 111333
   Summary: Runtime failure for fcmulcph instrinsic
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

cat main.cpp

#include 
#include 

__attribute__((optimize("O0")))
auto func0(_Float16 *a, _Float16 *b, int n, _Float16 *c) {
  __m512h rA = _mm512_loadu_ph(a);
  for (int i = 0; i < n; i += 32) {
__m512h rB = _mm512_loadu_ph(b + i);
_mm512_storeu_ph(c + i, _mm512_fcmul_pch(rB, rA));
  }
}

__attribute__((optimize("O2")))
auto func1(_Float16 *a, _Float16 *b, int n, _Float16 *c) {
  __m512h rA = _mm512_loadu_ph(a);
  for (int i = 0; i < n; i += 32) {
__m512h rB = _mm512_loadu_ph(b + i);
_mm512_storeu_ph(c + i, _mm512_fcmul_pch(rB, rA));
  }
}

int main() {
  int n = 32;

  _Float16 a[n], b[n], c[n];
  for (int i = 1; i <= n; i++) {
a[i - 1] = i & 1 ? -i : i;
b[i - 1] = i;
  }
  printf("a = %f + %fi \n", (float)a[0], (float)a[1]);
  printf("b = %f + %fi \n", (float)b[0], (float)b[1]);
  printf("b * conj(a) = %f + %fi \n\n", (float)(a[0]*b[0] + a[1]*b[1]),
(float)(a[0]*b[1] - a[1]*b[0]));

  func0(a, b, n, c);
for (int i = 0; i < n / 32 * 2; i++) {
  printf("%f ", (float)c[i]);
}
printf("\n");

  func1(a, b, n, c);
for (int i = 0; i < n / 32 * 2; i++) {
  printf("%f ", (float)c[i]);
}
printf("\n");

  return 0;
}

g++ -march=sapphirerapids main.cpp -o test
sde -spr-- ./test

a = -1.00 + 2.00i
b = 1.00 + 2.00i
b * conj(a) = 3.00 + -4.00i

3.00 -4.00
3.00 4.00

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||6.4.0
  Known to fail||7.3.0, 7.5.0, 8.5.0, 9.5.0

--- Comment #3 from Andrew Pinski  ---
GCC 11+ produces:
.L3:
vmovdqu (%rsi), %ymm2
vmovdqu 32(%rsi), %ymm1
subq$-128, %rdi
subq$-128, %rsi
vmovdqu -64(%rsi), %ymm0
vmovdqu -32(%rsi), %ymm3
vmovdqu %ymm2, -128(%rdi)
vmovdqu %ymm3, -32(%rdi)
vmovdqu %ymm1, -96(%rdi)
vmovdqu %ymm0, -64(%rdi)
cmpq%rax, %rdi
jne .L3

Which is the best code ...

[Bug target/111333] Runtime failure for fcmulcph instrinsic

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
fmulcph/fmaddcph is commutative for operands[1] and operands[2], but
fcmulcph/fcmaddcph is not, since it's Complex conjugate operations.

Below change fixes the issue.

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 6d3ae8dea0c..833546c5228 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -6480,6 +6480,14 @@ (define_int_attr complexpairopname
[(UNSPEC_COMPLEX_FMA_PAIR "fmaddc")
 (UNSPEC_COMPLEX_FCMA_PAIR "fcmaddc")])

+(define_int_attr int_comm
+   [(UNSPEC_COMPLEX_FMA "%")
+(UNSPEC_COMPLEX_FMA_PAIR "%")
+(UNSPEC_COMPLEX_FCMA "")
+(UNSPEC_COMPLEX_FCMA_PAIR "")
+(UNSPEC_COMPLEX_FMUL "%")
+(UNSPEC_COMPLEX_FCMUL "")])
+
 (define_int_attr conj_op
[(UNSPEC_COMPLEX_FMA "")
 (UNSPEC_COMPLEX_FCMA "_conj")
@@ -6593,7 +6601,7 @@ (define_expand "cmla4"
 (define_insn "fma__"
   [(set (match_operand:VHF_AVX512VL 0 "register_operand" "=&v")
(unspec:VHF_AVX512VL
- [(match_operand:VHF_AVX512VL 1 "" "%v")
+ [(match_operand:VHF_AVX512VL 1 ""
"v")
   (match_operand:VHF_AVX512VL 2 ""
"")
   (match_operand:VHF_AVX512VL 3 "" "0")]
   UNSPEC_COMPLEX_F_C_MA))]
@@ -6658,7 +,7 @@ (define_insn_and_split
"fma___fma_zero"
 (define_insn "fma___pair"
  [(set (match_operand:VF1_AVX512VL 0 "register_operand" "=&v")
(unspec:VF1_AVX512VL
-[(match_operand:VF1_AVX512VL 1 "vector_operand" "%v")
+[(match_operand:VF1_AVX512VL 1 "vector_operand" "v")
  (match_operand:VF1_AVX512VL 2 "bcst_vector_operand" "vmBr")
  (match_operand:VF1_AVX512VL 3 "vector_operand" "0")]
  UNSPEC_COMPLEX_F_C_MA_PAIR))]
@@ -6727,7 +6735,7 @@ (define_insn
"___mask"
   [(set (match_operand:VHF_AVX512VL 0 "register_operand" "=&v")
(vec_merge:VHF_AVX512VL
  (unspec:VHF_AVX512VL
-   [(match_operand:VHF_AVX512VL 1 "nonimmediate_operand" "%v")
+   [(match_operand:VHF_AVX512VL 1 "nonimmediate_operand"
"v")
 (match_operand:VHF_AVX512VL 2 "nonimmediate_operand"
"")
 (match_operand:VHF_AVX512VL 3 "register_operand" "0")]
 UNSPEC_COMPLEX_F_C_MA)
@@ -6752,7 +6760,7 @@ (define_expand "cmul3"
 (define_insn "__"
   [(set (match_operand:VHF_AVX512VL 0 "register_operand" "=&v")
  (unspec:VHF_AVX512VL
-   [(match_operand:VHF_AVX512VL 1 "nonimmediate_operand" "%v")
+   [(match_operand:VHF_AVX512VL 1 "nonimmediate_operand"
"v")
 (match_operand:VHF_AVX512VL 2 "nonimmediate_operand"
"")]
 UNSPEC_COMPLEX_F_C_MUL))]
   "TARGET_AVX512FP16 && "

[Bug target/111333] Runtime failure for fcmulcph instrinsic

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
The test failed since GCC12 when the pattern is added

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Anyways the tuning was fixed for GCC 11. GCC 10 is no longer supported so
closing as fixed for GCC 11.

[Bug target/111333] Runtime failure for fcmulcph instrinsic

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

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

--- Comment #3 from Andrew Pinski  ---
Isn't this a dup of bug 111306 ?

[Bug target/111333] Runtime failure for fcmulcph instrinsic

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Yes this is an exact dup.

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

[Bug target/111306] [12,13] macro-fusion makes error on conjugate complex multiplication fp16

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

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

[Bug target/111306] [12,13] macro-fusion makes error on conjugate complex multiplication fp16

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/111331] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu since

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

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

--- Comment #8 from Andrew Pinski  ---
The tree-ssa-phiopt.cc code is much more complex.

But not testing arg_true/arg_false against alt_larger/alt_smaller does fix the
issue.

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

[d_vampile at 163 dot com via Gcc-bugs]

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

--- Comment #5 from d_vampile  ---
According to the analysis, the following two prs may cause the preceding
problems:
PR1:https://github.com/gcc-mirror/gcc/commit/dd9b529f08c3c6064c37234922d298336d78caf7
PR2:https://github.com/gcc-mirror/gcc/commit/e7bf9583fa2a16e9edd5d5347407ad8acc8f9794

I revert PR1 on gcc10.3.0 and found that the assembly instructions changed to
vmovups and vmovups.

And revert PR2, the order of assembly instructions can be consistent with that
of instructions generated during gcc7.3.0 compilation. However, the effects  of
these two PRs and the potential risks of code rollback are still noclear.

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

[d_vampile at 163 dot com via Gcc-bugs]

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

--- Comment #6 from d_vampile  ---
GCC 7.3.0 produces:
extern __inline __m256i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm256_loadu_si256 (__m256i_u const *__P)
{
  return *__P;
  401170:   c5 fa 6f 1e vmovdqu (%rsi),%xmm3
dst = (uint8_t *)dst + 128;
  401174:   48 83 ef 80 sub$0xff80,%rdi
src = (const uint8_t *)src + 128;
  401178:   48 83 ee 80 sub$0xff80,%rsi
  40117c:   c5 fa 6f 56 a0  vmovdqu -0x60(%rsi),%xmm2
  401181:   c4 e3 65 38 5e 90 01vinserti128
$0x1,-0x70(%rsi),%ymm3,%ymm3
  401188:   c5 fa 6f 4e c0  vmovdqu -0x40(%rsi),%xmm1
  40118d:   c4 e3 6d 38 56 b0 01vinserti128
$0x1,-0x50(%rsi),%ymm2,%ymm2
  401194:   c5 fa 6f 46 e0  vmovdqu -0x20(%rsi),%xmm0
  401199:   c4 e3 75 38 4e d0 01vinserti128
$0x1,-0x30(%rsi),%ymm1,%ymm1
  4011a0:   c4 e3 7d 38 46 f0 01vinserti128
$0x1,-0x10(%rsi),%ymm0,%ymm0
}

extern __inline void __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm256_storeu_si256 (__m256i_u *__P, __m256i __A)
{
  *__P = __A;
  4011a7:   c5 f8 11 5f 80  vmovups %xmm3,-0x80(%rdi)
  4011ac:   c4 e3 7d 39 5f 90 01vextracti128 $0x1,%ymm3,-0x70(%rdi)
  4011b3:   c5 f8 11 57 a0  vmovups %xmm2,-0x60(%rdi)
  4011b8:   c4 e3 7d 39 57 b0 01vextracti128 $0x1,%ymm2,-0x50(%rdi)
  4011bf:   c5 f8 11 4f c0  vmovups %xmm1,-0x40(%rdi)
  4011c4:   c4 e3 7d 39 4f d0 01vextracti128 $0x1,%ymm1,-0x30(%rdi)
  4011cb:   c5 f8 11 47 e0  vmovups %xmm0,-0x20(%rdi)
  4011d0:   c4 e3 7d 39 47 f0 01vextracti128 $0x1,%ymm0,-0x10(%rdi)
while (n >= 128) {
  4011d7:   48 39 c7cmp%rax,%rdi
  4011da:   75 94   jne401170 
  4011dc:   c5 f8 77vzeroupper

In terms of runtime, this code is the best.