[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b

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

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

--- Comment #3 from Robin Dapp  ---
Yes, as agreed. Though today I probably won't be able to do much due to private
matters.

[Bug c/112665] I am getting incorrect output values at optimization level 2 in GCC for the s390x architecture.

[shinwogud12 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 신재형  ---
(In reply to 신재형 from comment #0)
> The provided C code includes a main function and a helper function i(),
> along with a struct definition and several global variables. The code
> primarily involves conditional logic and a loop to manipulate these global
> variables.
> 
> PoC(Proof of Concept)
> 
> #include 
> #include 
> 
> struct a {
>   uint64_t b;
> };
> int c = 1;
> int d, e, h, f, g, l = 0;
> volatile struct a k[1];
> 
> void i() {
>   for (; l < 1; l++)
> f = d <= 0;
> }
> 
> int main() {
>   for (e = 9; e; --e){
> i();
> c && (g = ((int16_t)(k[0], f)) <= e);
>   }
>   printf("g_200 value %d\n", g);
>   return 0;
> }
> 
> 
> Struct Definition
> 
> 
> struct a {
>   uint64_t b;
> };
> 
> - Defines a struct a with a single member b of type
> uint64_t.
> 
> Global Variables
> 
> 
> int c = 1;
> int d, e, h, f, g, l = 0;
> volatile struct a k[1];
> 
> 
> - A loop that runs once, setting **`f`** to 1 if **`d`** is less than or
> equal to 0.
> 
> Main Function
> 
> 
> cCopy code
> int main() {
>   for (e = 9; e; --e){
> i();
> c && (g = ((int16_t)(k[0], f)) <= e);
>   }
>   printf("g_200 value %d\n", g);
>   return 0;
> }
>
> 
> 
> - A loop starts with e at 9, decrementing until it reaches 0.
> - Calls function i(), which sets f based on the condition d
> <= 0
> - The expression c && (g = ((int16_t)(k[0], f)) <= e) uses the comma
> operator, resulting in f being evaluated and cast to int16_t.
> Since c is always 1, g is set to 1 if f is less than or
> equal to e.
> - The final value of g is printed.
> 
> ### Expected Result
> 
> - Since d is initialized to 0 and never modified, f will always
> be set to 1 in the i() function.
> - In the main function, g is set to 1 in each iteration of the loop
> because f (which is 1) is always less than or equal to e (which
> decrements from 9 to 1).
> - The final output of the program will be g_200 value 1.
> 
> Why does optimization level 2 in GCC output 0?
> 
> Godbolt Link: https://www.godbolt.org/z/r6c4oo18a

[Bug c/112665] New: I am getting incorrect output values at optimization level 2 in GCC for the s390x architecture.

[shinwogud12 at gmail dot com via Gcc-bugs]

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

Bug ID: 112665
   Summary: I am getting incorrect output values at optimization
level 2 in GCC for the s390x architecture.
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shinwogud12 at gmail dot com
  Target Milestone: ---

The provided C code includes a main function and a helper function i(), along
with a struct definition and several global variables. The code primarily
involves conditional logic and a loop to manipulate these global variables.

###PoC(Proof of Concept)
```
#include 
#include 

struct a {
  uint64_t b;
};
int c = 1;
int d, e, h, f, g, l = 0;
volatile struct a k[1];

void i() {
  for (; l < 1; l++)
f = d <= 0;
}

int main() {
  for (e = 9; e; --e){
i();
c && (g = ((int16_t)(k[0], f)) <= e);
  }
  printf("g_200 value %d\n", g);
  return 0;
}
```

**Struct Definition**

```
struct a {
  uint64_t b;
};
```
- Defines a struct **`a`** with a single member **`b`** of type **`uint64_t`**.

**Global Variables**

```c
int c = 1;
int d, e, h, f, g, l = 0;
volatile struct a k[1];
```

- A loop that runs once, setting **`f`** to 1 if **`d`** is less than or equal
to 0.

**Main Function**

```c
cCopy code
int main() {
  for (e = 9; e; --e){
i();
c && (g = ((int16_t)(k[0], f)) <= e);
  }
  printf("g_200 value %d\n", g);
  return 0;
}

```

- A loop starts with **`e`** at 9, decrementing until it reaches 0.
- Calls function **`i()`**, which sets **`f`** based on the condition **`d <=
0`**.
- The expression **`c && (g = ((int16_t)(k[0], f)) <= e)`** uses the comma
operator, resulting in **`f`** being evaluated and cast to **`int16_t`**. Since
**`c`** is always 1, **`g`** is set to 1 if **`f`** is less than or equal to
**`e`**.
- The final value of **`g`** is printed.

### Expected Result

- Since **`d`** is initialized to 0 and never modified, **`f`** will always be
set to 1 in the **`i()`** function.
- In the main function, **`g`** is set to 1 in each iteration of the loop
because **`f`** (which is 1) is always less than or equal to **`e`** (which
decrements from 9 to 1).
- The final output of the program will be **`g_200 value 1`**.

Why does optimization level 2 in GCC output 0?

Godbolt Link: https://www.godbolt.org/z/r6c4oo18a

[Bug middle-end/112344] [14 Regression] Wrong code at -O2 on x86_64-pc-linux-gnu

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

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

--- Comment #7 from Richard Biener  ---
Ah, it reproduces (a local patch hides the issue, the bisected rev. likely just
exposes an existing issue).

We're optimizing this to

   [local count: 16873086]:

   [local count: 105119324]:
  # c_31 = PHI <3(2), c_51(3)>
  # ivtmp_28 = PHI <7(2), ivtmp_49(3)>
  _48 = (unsigned char) c_31;
  _50 = _48 + 10;
  c_51 = (signed char) _50;
  ivtmp_49 = ivtmp_28 + 4294967295;
  if (ivtmp_49 != 0)
goto ; [85.71%]
  else
goto ; [14.29%]

   [local count: 16873086]:
  d_52 = (short int) _50;
  if (d_52 != 13)

and the issue is likely in final value replacement doing

final value replacement:
  e_9 = PHI 
 with expr: (e_31 + 2) + (int) ((19 - (unsigned int) e_31) / 2) * 2
 final stmt:
  e_9 = _7 + _20;


final value replacement:
  c_8 = PHI 
 with expr: (signed char) (((unsigned char) ((19 - (unsigned int) e_31) / 2) +
(unsigned char) c_25) + 1)
 final stmt:
  c_8 = (signed char) _33;


-fdisable-tree-sccp fixes this.

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #25 from rguenther at suse dot de  ---
On Tue, 21 Nov 2023, bugdal at aerifal dot cx wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
> 
> Rich Felker  changed:
> 
>What|Removed |Added
> 
>  CC||bugdal at aerifal dot cx
> 
> --- Comment #24 from Rich Felker  ---
> If the copy is such that gcc is happy to emit an external call to memcpy for
> it, there is no significant size or performance cost to emitting a branch
> checking for equality before making the call, and performing this branch would
> greatly optimize the (maybe rare in the caller, maybe not) case of
> self-assignment!
> 
> On the other hand, expecting the libc memcpy to make this check greatly
> pessimizes every reasonable small use of memcpy with a gratuitous branch for
> what is undefined behavior and should never appear in any valid program.
> 
> Fix it on the compiler side please.

The only reasonable fix on the compiler side is to never emit memcpy
but always use memmove.  The pessimization of that compared to the
non-existing "real" issue with calling memcpy with exact overlap
is the reason for the non-action.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b

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

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

--- Comment #2 from JuzheZhong  ---
(In reply to Robin Dapp from comment #1)
> Confirmed, smaller example:
> 
> program main
>   implicit none
>   integer, parameter :: n=5
>   character(len=6), dimension(n,n) :: a
>   character(len=6), dimension(n) :: r1
>   integer :: i
>   logical, dimension(n,n) :: mask
> 
>   write (unit=a,fmt='(I6.6)') (i*i+200-17*i,i=1,n*n)
>   mask = .true.
>   forall (i=1:n)
>  mask(i,i) = .false.
>   end forall
> 
>   r1 = maxval(a, dim=1, mask=mask)
> 
> end program main
> 
> compiled with -O3 -march=rv64gcv_zvl256b

Thanks Robin.

I am gonna work on C/C++ bugs. You work on fortran so that we won't do
duplicate 
work. Is that OK for you ?

Thanks.

[Bug target/112643] [14 regression] including x86intrin.h is broken for -march=native (which adds -mno-avx10.1-256 )

[haochen.jiang at intel dot com via Gcc-bugs]

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

--- Comment #22 from Haochen Jiang  ---
A quick workaround would be not appending -mno-avx10.1-xxx into -march=native.
And it should work after my experiment. However, I am finding a better way to
do that.

The real problem seems like the AVX10 and AVX512 options handling in override
part messed up flags while both explicit no on options and finally messed up
the pragma push in avx512vp2intersect since it is the only AVX512 ISA out of
AVX10.1 except for Xeon Phi.

[Bug target/112598] RISC-V regression testsuite errors with rv64gcv_zvl512b

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

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

--- Comment #5 from CVS Commits  ---
The trunk branch has been updated by Lehua Ding :

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

commit r14-5748-gd13e59b86c5cbeec6135ada3f6dc983289cac610
Author: Juzhe-Zhong 
Date:   Wed Nov 22 11:27:52 2023 +0800

RISC-V: Fix permutation indice mode bug

This patch fixes following FAILs on zvl512b:
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-1.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-1.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-16.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-16.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-17.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-17.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-3.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-3.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-5.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-5.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-6.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-6.c execution test

The root cause is that we are using vrgather.vv on vector QI mode which
is incorrect for zvl512b since it exceed 256.

Instead, we should use vrgatherei16.vv

PR target/112598

gcc/ChangeLog:

* config/riscv/riscv-v.cc (emit_vlmax_gather_insn): Adapt the
priority.
(shuffle_generic_patterns): Fix permutation indice bug.
* config/riscv/vector-iterators.md: Fix VEI16 bug.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr112598-2.c: New test.

[Bug c++/86286] Could __attribute__ ((nothrow)) on a noexcept function turn off EH codegen?

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #6 from Julian Waters  ---
Just tested this on gcc 13, MinGW, a noexcept method includes the .seh_handler
instruction in the compiled assembly, signifying the creation of Windows
exception handling tables, while [[gnu::nothrow]] does not. So it seems to me
that nothrow is not exactly mapped to noexcept

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b

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

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

--- Comment #1 from Robin Dapp  ---
Confirmed, smaller example:

program main
  implicit none
  integer, parameter :: n=5
  character(len=6), dimension(n,n) :: a
  character(len=6), dimension(n) :: r1
  integer :: i
  logical, dimension(n,n) :: mask

  write (unit=a,fmt='(I6.6)') (i*i+200-17*i,i=1,n*n)
  mask = .true.
  forall (i=1:n)
 mask(i,i) = .false.
  end forall

  r1 = maxval(a, dim=1, mask=mask)

end program main

compiled with -O3 -march=rv64gcv_zvl256b

[Bug target/111488] ICE ion riscv gcc.dg/vect/vect-126.c

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

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

Robin Dapp  changed:

   What|Removed |Added

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

--- Comment #4 from Robin Dapp  ---
Fixed.

[Bug tree-optimization/111796] OMP SIMD call vectorization fails for arguments subject to integer promotion rules

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-22
 Ever confirmed|0   |1

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

[Bug target/112611] LoongArch: Test cases lsx-vshuf.c and lasx-xvshuf_b.c fails on LA664

[xujiahao at loongson dot cn via Gcc-bugs]

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

--- Comment #3 from Jiahao Xu  ---
(In reply to Xi Ruoyao from comment #2)
> (In reply to Jiahao Xu from comment #1)
> > Due to some issues with the implementation of the [x]vshuf instruction in
> > LA464, there is a problem where, when the index value in the register is
> > greater than or equal to 64, it fails to perform modulo operation to obtain
> > a new index for selecting the corresponding element. Instead, it directly
> > writes a 0 to the destination register. LA664 has fixed this issue.
> > 
> > The expected results in these two files are not the correct results, but
> > rather the results obtained directly using the [x]vshuf instruction on
> > la464. This is why they fail on LA664. Now, there are two possible
> > solutions. One is to delete these two problematic test cases, as you
> > suggested. The other solution is to modify the expected results to the
> > correct ones and only test these two files on LA664. We are currently
> > considering which option to choose.
> 
> Maybe just rewriting the results to match LA664, and invoke CPUCFG to skip
> these tests for any other implementations?
> 
> In the future we better assign a CPUCFG bit to indicate this.

We now consider it as undefined behavior rather than a bug for [x]vshuf
instructions. In vec_perm pattern, we use vector logical AND instructions to
perform modulo operations in order to correctly use the [x]vshuf instructions.
Therefore, we have decided to rewrite the two tests and ensure that the index
values in the selector do not exceed 64.

[Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c

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

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

Maciej W. Rozycki  changed:

   What|Removed |Added

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

--- Comment #6 from Maciej W. Rozycki  ---
Fix now committed and backported to GCC 13/12/11.  Closing bug.

[Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Maciej W. Rozycki
:

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

commit r11-11108-g66a4094112c446ec16733c687e4b3813519da66b
Author: Maciej W. Rozycki 
Date:   Wed Nov 22 01:27:02 2023 +

PR target/111815: VAX: Only accept the index scaler as the RHS operand to
ASHIFT

As from commit 9df1ba9a35b8 ("libbacktrace: support zstd decompression")
GCC for the `vax-netbsdelf' target fails to complete building, with an
ICE:

during RTL pass: final
.../libbacktrace/elf.c: In function 'elf_zstd_decompress':
.../libbacktrace/elf.c:5006:1: internal compiler error: in
print_operand_address, at config/vax/vax.cc:514
 5006 | }
  | ^
0x1113df97 print_operand_address(_IO_FILE*, rtx_def*)
.../gcc/config/vax/vax.cc:514
0x10c2489b default_print_operand_address(_IO_FILE*, machine_mode, rtx_def*)
.../gcc/targhooks.cc:373
0x106ddd0b output_address(machine_mode, rtx_def*)
.../gcc/final.cc:3648
0x106ddd0b output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3505
0x106e2143 output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3421
0x106e2143 final_scan_insn_1
.../gcc/final.cc:2841
0x106e28e3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.../gcc/final.cc:2887
0x106e2bf7 final_1
.../gcc/final.cc:1979
0x106e3c67 rest_of_handle_final
.../gcc/final.cc:4240
0x106e3c67 execute
.../gcc/final.cc:4318
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.

This is due to combine producing an invalid address RTX:

(plus:SI (ashift:SI (const_int 1 [0x1])
(reg:QI 3 %r3 [1232]))
(reg/v:SI 10 %r10 [orig:736 weight_mask ] [736]))

where the expression is ((1 << R3) + R10), which does not match a valid
machine addressing mode.  Consequently `print_operand_address' chokes.

This can be reduced to the testcase included, where it triggers the same
ICE in `p'.  Preincrements are required so that their results land in
registers and consequently an indexed addressing mode is tried or
otherwise doing operations piecemeal on stack-based function arguments
as direct input operands turns out more profitable in terms of RTX costs
and the ICE is avoided.

The ultimate cause has been commit c605a8bf9270 ("VAX: Accept ASHIFT in
address expressions"), where a shift of an immediate value by a register
has been mistakenly allowed as an index expression as if the shift
operation was commutative such as multiplication is.  So with ASHIFT the
scaler in an index expression has to be the right-hand operand, and the
backend has to enforce that, whereas with MULT the scaler can be either
operand.

Fix this by only accepting the index scaler as the RHS operand to
ASHIFT.

gcc/
PR target/111815
* config/vax/vax.c (index_term_p): Only accept the index scaler
as the RHS operand to ASHIFT.

gcc/testsuite/
PR target/111815
* gcc.dg/torture/pr111815.c: New test.

(cherry picked from commit 56ff988e6be3fdba70cad86d73ec0038bc3b6b5a)

[Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Maciej W. Rozycki
:

https://gcc.gnu.org/g:31bc12b6bb3fd56a65d1f73dcc4fcfad6486361c

commit r12-9998-g31bc12b6bb3fd56a65d1f73dcc4fcfad6486361c
Author: Maciej W. Rozycki 
Date:   Wed Nov 22 01:27:02 2023 +

PR target/111815: VAX: Only accept the index scaler as the RHS operand to
ASHIFT

As from commit 9df1ba9a35b8 ("libbacktrace: support zstd decompression")
GCC for the `vax-netbsdelf' target fails to complete building, with an
ICE:

during RTL pass: final
.../libbacktrace/elf.c: In function 'elf_zstd_decompress':
.../libbacktrace/elf.c:5006:1: internal compiler error: in
print_operand_address, at config/vax/vax.cc:514
 5006 | }
  | ^
0x1113df97 print_operand_address(_IO_FILE*, rtx_def*)
.../gcc/config/vax/vax.cc:514
0x10c2489b default_print_operand_address(_IO_FILE*, machine_mode, rtx_def*)
.../gcc/targhooks.cc:373
0x106ddd0b output_address(machine_mode, rtx_def*)
.../gcc/final.cc:3648
0x106ddd0b output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3505
0x106e2143 output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3421
0x106e2143 final_scan_insn_1
.../gcc/final.cc:2841
0x106e28e3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.../gcc/final.cc:2887
0x106e2bf7 final_1
.../gcc/final.cc:1979
0x106e3c67 rest_of_handle_final
.../gcc/final.cc:4240
0x106e3c67 execute
.../gcc/final.cc:4318
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.

This is due to combine producing an invalid address RTX:

(plus:SI (ashift:SI (const_int 1 [0x1])
(reg:QI 3 %r3 [1232]))
(reg/v:SI 10 %r10 [orig:736 weight_mask ] [736]))

where the expression is ((1 << R3) + R10), which does not match a valid
machine addressing mode.  Consequently `print_operand_address' chokes.

This can be reduced to the testcase included, where it triggers the same
ICE in `p'.  Preincrements are required so that their results land in
registers and consequently an indexed addressing mode is tried or
otherwise doing operations piecemeal on stack-based function arguments
as direct input operands turns out more profitable in terms of RTX costs
and the ICE is avoided.

The ultimate cause has been commit c605a8bf9270 ("VAX: Accept ASHIFT in
address expressions"), where a shift of an immediate value by a register
has been mistakenly allowed as an index expression as if the shift
operation was commutative such as multiplication is.  So with ASHIFT the
scaler in an index expression has to be the right-hand operand, and the
backend has to enforce that, whereas with MULT the scaler can be either
operand.

Fix this by only accepting the index scaler as the RHS operand to
ASHIFT.

gcc/
PR target/111815
* config/vax/vax.cc (index_term_p): Only accept the index scaler
as the RHS operand to ASHIFT.

gcc/testsuite/
PR target/111815
* gcc.dg/torture/pr111815.c: New test.

(cherry picked from commit 56ff988e6be3fdba70cad86d73ec0038bc3b6b5a)

[Bug c/112647] Inconsistent Comparison Results of Unsigned Bit Fields Across Different Compilers and Architectures

[guminb at ajou dot ac.kr via Gcc-bugs]

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

--- Comment #2 from gyumin  ---
Thank you for your kind reply

[Bug target/112643] [14 regression] including x86intrin.h is broken for -march=native (which adds -mno-avx10.1-256 )

[haochen.jiang at intel dot com via Gcc-bugs]

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

--- Comment #21 from Haochen Jiang  ---
(In reply to Andrew Pinski from comment #20)
> The use of __builtin_ia32_2intersectd128 in avx512vp2intersectvlintrin.h has:
> #pragma GCC target("avx512vp2intersect,avx512vl,no-evex512")
> 
> While i386-builtin.def does:
> BDESC (0, OPTION_MASK_ISA2_AVX512VP2INTERSECT, CODE_FOR_nothing,
> "__builtin_ia32_2intersectd128", IX86_BUILTIN_2INTERSECTD128, UNKNOWN, (int)
> VOID_FTYPE_PUQI_PUQI_V4SI_V4SI)

This is a known issue I figured out yesterday but should not cause the problem
since it actually relaxed conditions. It will cause ICE when caliing builtins
directly.

The reason why I am not reproducing the regression seems mainly caused by the
machine I built with all have AVX512, but all the CPUs mentioned here did not,
which will lead to different behavior on march and option override.

Rebuilding on AVX only machine to reproduce.

[Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Maciej W. Rozycki
:

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

commit r13-8089-g2c23fa691d23d9f3d57ac7feece6fbbb7236c563
Author: Maciej W. Rozycki 
Date:   Wed Nov 22 01:27:02 2023 +

PR target/111815: VAX: Only accept the index scaler as the RHS operand to
ASHIFT

As from commit 9df1ba9a35b8 ("libbacktrace: support zstd decompression")
GCC for the `vax-netbsdelf' target fails to complete building, with an
ICE:

during RTL pass: final
.../libbacktrace/elf.c: In function 'elf_zstd_decompress':
.../libbacktrace/elf.c:5006:1: internal compiler error: in
print_operand_address, at config/vax/vax.cc:514
 5006 | }
  | ^
0x1113df97 print_operand_address(_IO_FILE*, rtx_def*)
.../gcc/config/vax/vax.cc:514
0x10c2489b default_print_operand_address(_IO_FILE*, machine_mode, rtx_def*)
.../gcc/targhooks.cc:373
0x106ddd0b output_address(machine_mode, rtx_def*)
.../gcc/final.cc:3648
0x106ddd0b output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3505
0x106e2143 output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3421
0x106e2143 final_scan_insn_1
.../gcc/final.cc:2841
0x106e28e3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.../gcc/final.cc:2887
0x106e2bf7 final_1
.../gcc/final.cc:1979
0x106e3c67 rest_of_handle_final
.../gcc/final.cc:4240
0x106e3c67 execute
.../gcc/final.cc:4318
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.

This is due to combine producing an invalid address RTX:

(plus:SI (ashift:SI (const_int 1 [0x1])
(reg:QI 3 %r3 [1232]))
(reg/v:SI 10 %r10 [orig:736 weight_mask ] [736]))

where the expression is ((1 << R3) + R10), which does not match a valid
machine addressing mode.  Consequently `print_operand_address' chokes.

This can be reduced to the testcase included, where it triggers the same
ICE in `p'.  Preincrements are required so that their results land in
registers and consequently an indexed addressing mode is tried or
otherwise doing operations piecemeal on stack-based function arguments
as direct input operands turns out more profitable in terms of RTX costs
and the ICE is avoided.

The ultimate cause has been commit c605a8bf9270 ("VAX: Accept ASHIFT in
address expressions"), where a shift of an immediate value by a register
has been mistakenly allowed as an index expression as if the shift
operation was commutative such as multiplication is.  So with ASHIFT the
scaler in an index expression has to be the right-hand operand, and the
backend has to enforce that, whereas with MULT the scaler can be either
operand.

Fix this by only accepting the index scaler as the RHS operand to
ASHIFT.

gcc/
PR target/111815
* config/vax/vax.cc (index_term_p): Only accept the index scaler
as the RHS operand to ASHIFT.

gcc/testsuite/
PR target/111815
* gcc.dg/torture/pr111815.c: New test.

(cherry picked from commit 56ff988e6be3fdba70cad86d73ec0038bc3b6b5a)

[Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Maciej W. Rozycki :

https://gcc.gnu.org/g:56ff988e6be3fdba70cad86d73ec0038bc3b6b5a

commit r14-5745-g56ff988e6be3fdba70cad86d73ec0038bc3b6b5a
Author: Maciej W. Rozycki 
Date:   Wed Nov 22 01:27:02 2023 +

PR target/111815: VAX: Only accept the index scaler as the RHS operand to
ASHIFT

As from commit 9df1ba9a35b8 ("libbacktrace: support zstd decompression")
GCC for the `vax-netbsdelf' target fails to complete building, with an
ICE:

during RTL pass: final
.../libbacktrace/elf.c: In function 'elf_zstd_decompress':
.../libbacktrace/elf.c:5006:1: internal compiler error: in
print_operand_address, at config/vax/vax.cc:514
 5006 | }
  | ^
0x1113df97 print_operand_address(_IO_FILE*, rtx_def*)
.../gcc/config/vax/vax.cc:514
0x10c2489b default_print_operand_address(_IO_FILE*, machine_mode, rtx_def*)
.../gcc/targhooks.cc:373
0x106ddd0b output_address(machine_mode, rtx_def*)
.../gcc/final.cc:3648
0x106ddd0b output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3505
0x106e2143 output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3421
0x106e2143 final_scan_insn_1
.../gcc/final.cc:2841
0x106e28e3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.../gcc/final.cc:2887
0x106e2bf7 final_1
.../gcc/final.cc:1979
0x106e3c67 rest_of_handle_final
.../gcc/final.cc:4240
0x106e3c67 execute
.../gcc/final.cc:4318
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.

This is due to combine producing an invalid address RTX:

(plus:SI (ashift:SI (const_int 1 [0x1])
(reg:QI 3 %r3 [1232]))
(reg/v:SI 10 %r10 [orig:736 weight_mask ] [736]))

where the expression is ((1 << R3) + R10), which does not match a valid
machine addressing mode.  Consequently `print_operand_address' chokes.

This can be reduced to the testcase included, where it triggers the same
ICE in `p'.  Preincrements are required so that their results land in
registers and consequently an indexed addressing mode is tried or
otherwise doing operations piecemeal on stack-based function arguments
as direct input operands turns out more profitable in terms of RTX costs
and the ICE is avoided.

The ultimate cause has been commit c605a8bf9270 ("VAX: Accept ASHIFT in
address expressions"), where a shift of an immediate value by a register
has been mistakenly allowed as an index expression as if the shift
operation was commutative such as multiplication is.  So with ASHIFT the
scaler in an index expression has to be the right-hand operand, and the
backend has to enforce that, whereas with MULT the scaler can be either
operand.

Fix this by only accepting the index scaler as the RHS operand to
ASHIFT.

gcc/
PR target/111815
* config/vax/vax.cc (index_term_p): Only accept the index scaler
as the RHS operand to ASHIFT.

gcc/testsuite/
PR target/111815
* gcc.dg/torture/pr111815.c: New test.

[Bug middle-end/112664] missed-optimization: extra comparison when reordering statements

[goon.pri.low at gmail dot com via Gcc-bugs]

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

--- Comment #4 from gooncreeper  ---
(In reply to Andrew Pinski from comment #1)
> Dup.
> 
> *** This bug has been marked as a duplicate of bug 105496 ***

Apologies.
Though, how are you so good at finding duplicates? What's the secret?(In reply
to Andrew Pinski from comment #3)
> (In reply to gooncreeper from comment #2)
> > Though, how are you so good at finding duplicates? What's the secret?
> 
> Everyone says I have bugzilla memorized but I don't, I am just really code
> at doing keyword searches and knowing what keywords to search for. In this
> case I searched for "canonical compare" because I knew this was a
> canonicalization issue with how GCC changed `v < 6` into `v <= 5`

Ah, if I knew the fancy names of optimizations I would probably be a bit better
at checking my finds.

[Bug c++/110158] Cannot use union with std::string inside in constant expression

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

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

--- Comment #8 from Patrick Palka  ---
It seems the comment #4 testcase is still rejected on trunk after/despite
r14-4334-g28adad7a32ed92?

[Bug middle-end/112664] missed-optimization: extra comparison when reordering statements

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to gooncreeper from comment #2)
> Though, how are you so good at finding duplicates? What's the secret?

Everyone says I have bugzilla memorized but I don't, I am just really code at
doing keyword searches and knowing what keywords to search for. In this case I
searched for "canonical compare" because I knew this was a canonicalization
issue with how GCC changed `v < 6` into `v <= 5`

[Bug c++/112658] [12/13/14 Regression] ICE: finish_expr_stmt with casting an temp array to pointer and constructor call

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Keywords|needs-bisection |wrong-code
 Status|NEW |ASSIGNED
 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
The ICE-on-valid started with r12-2233-gb9119edc09e466, but before that this
was wrong-code:

bool called;
struct foo{
  foo(const int *new_mac) { called = true; }
};

typedef int t[1];
int main() {
  foo f((int*)t{ 0xFC});
  if (!called) __builtin_abort();
}

If we do copy initialization instead of direct initialization then we ICE ever
since the sanity check assert was added in r6-6795-g0fd9d4921f7ba2

[Bug middle-end/112664] missed-optimization: extra comparison when reordering statements

[goon.pri.low at gmail dot com via Gcc-bugs]

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

--- Comment #2 from gooncreeper  ---
(In reply to Andrew Pinski from comment #1)
> Dup.
> 
> *** This bug has been marked as a duplicate of bug 105496 ***

Apologies.
Though, how are you so good at finding duplicates? What's the secret?

[Bug middle-end/112664] missed-optimization: extra comparison when reordering statements

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug target/105496] Comparison optimizations result in unnecessary cmp instructions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||goon.pri.low at gmail dot com

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

[Bug middle-end/112664] missed-optimization: extra comparison when reordering statements

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug middle-end/112664] New: missed-optimization: extra comparison when reordering statements

[goon.pri.low at gmail dot com via Gcc-bugs]

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

Bug ID: 112664
   Summary: missed-optimization: extra comparison when reordering
statements
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goon.pri.low at gmail dot com
  Target Milestone: ---

These two functions which you would expect to be essentially equivalent, has
the first one with an extra comparison.

int unopt(int v) {
if (v < 6) {
return 15;
}

if (v > 6) {
return 3;
}

return 9;
}

unopt:
mov eax, 15
cmp edi, 5
jle .L1
cmp edi, 6
mov eax, 3
mov edx, 9
cmove   eax, edx
.L1:
ret

The second one it reuses the old comparison.

int opt(int v) {
if (v > 6) {
return 3;
}

if (v < 6) {
return 15;
}

return 9;
}

opt:
mov eax, 3
cmp edi, 6
jg  .L6
mov eax, 15
mov edx, 9
cmove   eax, edx
.L6:
ret

[Bug middle-end/65855] SCEV / SCCP missing optimization: triangular numbers

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||goon.pri.low at gmail dot com

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

[Bug middle-end/112663] missed-optimization: sum of 1 to n

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords|missed-optimization |
 Resolution|--- |DUPLICATE

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

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

[Bug middle-end/112663] New: missed-optimization: sum of 1 to n

[goon.pri.low at gmail dot com via Gcc-bugs]

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

Bug ID: 112663
   Summary: missed-optimization: sum of 1 to n
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goon.pri.low at gmail dot com
  Target Milestone: ---

This code which calculates the sum of 1 + 2 + .. n

unsigned unopt(unsigned n) {
unsigned k = 0;

for (unsigned i = 1; i <= n; i++)
k += i;

return k;
}

Could be optimized to this mathematical formula:

unsigned opt(unsigned n) {
return n * (n + 1) / 2;
}

[Bug target/112531] [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable

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

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2023-11-21
 Ever confirmed|0   |1
 CC||palmer at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #5 from palmer at gcc dot gnu.org ---
(In reply to Robin Dapp from comment #4)
> Personally, I don't mind having some FAILs as long as we know them and
> understand the reason for them.   I wouldn't insist on "fixing" them but
> don't mind if others prefer to have the results "clean".  Probably a matter
> of taste.

IIUC every target still has some FAILs, so it's kind of just par for the
course.  That said, if we're going to put the work into root causing the
failure far enough to determine it's invalid then we're most of the way to just
making the failure disappear.  I guess it's a little more work upfront, but
otherwise everyone has to maintain some list of "tests that FAIL, but we're
ignoring".  We had some of that in the riscv-gnu-toolchain allowlist, but even
then it becomes clunky to maintain.

So I think we're unlikely to ever get them all, but at least for the ones that
are somewhat easy to root cause I think we might as well just fix them.  I just
sent along a fix for this one:
https://inbox.sourceware.org/gcc-patches/20231121232704.12336-5-pal...@rivosinc.com/

[Bug sanitizer/112353] asan-enabled, aarch64-gcc cross-compiled elf executables fail ro run in qemu-user on x86

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Interesting using qemu 8.1.2 works but using qemu 6.2.0 does not.

Looks like a qemu issue and not a GCC one.

[Bug middle-end/112662] missed-optimization: loop increment until wrap

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Ever confirmed|0   |1
   Severity|normal  |enhancement
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Last reconfirmed||2023-11-21

--- Comment #1 from Andrew Pinski  ---
```
unsigned f(unsigned a)
{
  unsigned t = a+1;
  bool tt = t > 999;
  unsigned t3 = ~a;
  unsigned t4;
  if (tt) t4 = t3; else t4 = 0;
  return t+t4;
}
```
Is only optimized by PRE.
Which does not optimize GIMPLE_COND plus it is too late.

Anyways we have:

  _6 = a_2(D) + 1;
  _7 = _6 > 999;
  _8 = ~a_2(D);
  _9 = _7 ? _8 : 0;
  a_4 = _6 + _9;

Which could be optimized to:
  _6 = a_2(D) + 1;
  _7 = _6 > 999;
  a_4 = _7 ? 0 : _6;

Maybe something like:
```
(simplify
 (plus:c (plus@0 @1 integer_onep)
 (cond @2 (bit_not @0) integer_zerop@3))
 (cond @2 @3 @0))
```

I will look into this further, maybe that is it.

[Bug middle-end/112662] New: missed-optimization: loop increment until wrap

[goon.pri.low at gmail dot com via Gcc-bugs]

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

Bug ID: 112662
   Summary: missed-optimization: loop increment until wrap
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goon.pri.low at gmail dot com
  Target Milestone: ---

This function:

unsigned unopt(unsigned a) {
while (++a > 999);
return a;
}

unopt:
lea eax, [rdi+1]
xor edx, edx
not edi
cmp eax, 999
cmovbe  edi, edx
add eax, edi
ret

Can be optimized to:

unsigned opt(unsigned a) {
if (++a > 999) return a;
return 0;
}

opt:
lea eax, [rdi+1]
xor edx, edx
cmp eax, 999
cmovbe  eax, edx
ret

(saving two valuable instructions)

[Bug target/112597] RISC-V regression testsuite errors with rv64gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #8 from Patrick O'Neill  ---
(In reply to JuzheZhong from comment #7)
> I think there is middle-end issue here:
> 
> FAIL: gfortran.dg/maxval_char_3.f90   -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
> error: in duplicate_and_interleave, at tree-vect-slp.cc:8025)
> 
> Could you file another PR CC me, Robin and Richard for this ?

Filed: pr112661

[Bug c++/112658] [12/13/14 Regression] ICE: finish_expr_stmt with casting an temp array to pointer and constructor call

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> Hmm GCC rejects:
> ```
> struct foo{
>   foo(const int *new_mac);
> };
> typedef int t[1];
> 
> void g(){
>   foo f(t{ 0xFC});
> }
> ```
> While clang, MSVC all accepts it ...

Oh wait that is PR 94264.

[Bug c++/112658] [12/13/14 Regression] ICE: finish_expr_stmt with casting an temp array to pointer and constructor call

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

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

--- Comment #3 from Andrew Pinski  ---
Hmm GCC rejects:
```
struct foo{
  foo(const int *new_mac);
};
typedef int t[1];

void g(){
  foo f(t{ 0xFC});
}
```
While clang, MSVC all accepts it ...

[Bug middle-end/112661] New: [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112661
   Summary: [14] RISC-V ICE: in duplicate_and_interleave, at
tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Found on pr112597, GCC hash: 30d8188e6d1b450533ab0055b951ebfc75022219
Replicated using 7a496b7ce105185be12e023e749c90d5f7561879 since that's what I
had on hand.

> ./bin/riscv64-unknown-linux-gnu-gcc -march=rv64gcv_zvl256b -mabi=lp64d -O3 
> maxval_char_3.f90 -freport-bug
during GIMPLE pass: vect
maxval_char_3.f90:2:12:

2 | program main
  |^
internal compiler error: in duplicate_and_interleave, at tree-vect-slp.cc:8025
0xa8fb27 duplicate_and_interleave(vec_info*, gimple**, tree_node*,
vec const&, unsigned int, vec&)
../../../gcc/gcc/tree-vect-slp.cc:8025
0x15e04b5 vect_create_constant_vectors
../../../gcc/gcc/tree-vect-slp.cc:8246
0x15e04b5 vect_schedule_slp_node
../../../gcc/gcc/tree-vect-slp.cc:9052
0x15f39ff vect_schedule_scc
../../../gcc/gcc/tree-vect-slp.cc:9433
0x15f4698 vect_schedule_scc
../../../gcc/gcc/tree-vect-slp.cc:9450
0x15f4da7 vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
../../../gcc/gcc/tree-vect-slp.cc:9614
0x15c3aeb vect_transform_loop(_loop_vec_info*, gimple*)
../../../gcc/gcc/tree-vect-loop.cc:11710
0x1605791 vect_transform_loops
../../../gcc/gcc/tree-vectorizer.cc:1006
0x1605f03 try_vectorize_loop_1
../../../gcc/gcc/tree-vectorizer.cc:1152
0x1605f03 try_vectorize_loop
../../../gcc/gcc/tree-vectorizer.cc:1182
0x1606514 execute
../../../gcc/gcc/tree-vectorizer.cc:1298
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

-freport bug does not seem to generate any output so please let me know if you
need any additional info:

> ./bin/riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=./bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/scratch/tc-testing/bisect-issue/hash-7a496b7ce105185be12e023e749c90d5f7561879/libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with:
/scratch/tc-testing/bisect-issue/hash-7a496b7ce105185be12e023e749c90d5f7561879/../gcc/configure
--target=riscv64-unknown-linux-gnu
--prefix=/scratch/tc-testing/bisect-issue/hash-7a496b7ce105185be12e023e749c90d5f7561879
--with-sysroot=/scratch/tc-testing/bisect-issue/hash-7a496b7ce105185be12e023e749c90d5f7561879/sysroot
--with-pkgversion=g7a496b7ce10 --with-system-zlib --enable-shared --enable-tls
--enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap
--src=../../gcc --enable-multilib --with-abi=lp64d --with-arch=rv64imafdc
--with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2   
-mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medlow'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231116 (experimental) (g7a496b7ce10)

Source file:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gfortran.dg/maxval_char_3.f90;h=cc41ae049fb4920f0148f9c470071d6b940527c4;hb=7a496b7ce105185be12e023e749c90d5f7561879

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to gooncreeper from comment #4)
> I am not quite testing on the trunk build but I also believe modulo

Yes but only powers of 2. Due to the conversions to using &.

[Bug c++/112658] [12/13/14 Regression] ICE: finish_expr_stmt with casting an temp array to pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[12/13/14 Regression] ICE:  |[12/13/14 Regression] ICE:
   |finish_expr_stmt , at   |finish_expr_stmt with
   |cp/semantics.cc:892 |casting an temp array to
   ||pointer

--- Comment #2 from Andrew Pinski  ---
Here is a better testcase:
```
struct foo{
  foo(const int *new_mac);
};

typedef int t[1];
void g(){
  foo f((int*)t{ 0xFC});
}
```

Which is definitely valid code.

[Bug target/112651] RISC-V Vector new option -mvect-lmul required to force LMUL values (rather than --param=riscv-autovec-lmul to hint at values)

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

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

JuzheZhong  changed:

   What|Removed |Added

 CC||juzhe.zhong at rivai dot ai

--- Comment #3 from JuzheZhong  ---
The reason we use --param=riscv-autovec-lmul instead of -mvect-lmul which is
not documented because we don't have ratifed compile option.

I have mentioned whether we should have -mrvv-vector-lmul but LLVM people
object
it.

https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/33

[Bug c++/112658] [12/13/14 Regression] ICE: finish_expr_stmt , at cp/semantics.cc:892

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |12.4
Summary|ICE: finish_expr_stmt , at  |[12/13/14 Regression] ICE:
   |cp/semantics.cc:892 |finish_expr_stmt , at
   ||cp/semantics.cc:892
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-21
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
struct foo{
  foo(const int *new_mac);
};

void g(){
  foo f((int*)((int[1]){ 0xFC}));
}

```

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

[goon.pri.low at gmail dot com via Gcc-bugs]

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

--- Comment #4 from gooncreeper  ---
(In reply to Andrew Pinski from comment #2)
> >Note: this happens for all operators, not just addition!
> 
> Actually it is just addition with a constant on the trunk.
> ```
> int g(int v, int b) {
> if (v - b)
> return v - b ;
> else
> return 0;
> }
> ```
> was handled with PR 19832.
> 
> 
> I see division with a constant is not handled though:
> ```
> int unopt(int v, int b) {
> if (v /2)
> return v / 2;
> else
> return 0;
> }
> ```


I am not quite testing on the trunk build but I also believe modulo

[Bug target/112648] RISC-V Vector parameter riscv-autovec-lmul value is ineffective

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

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

JuzheZhong  changed:

   What|Removed |Added

 CC||juzhe.zhong at rivai dot ai

--- Comment #4 from JuzheZhong  ---
Rather than talk about the compile option.

I confirm the riscv-autovec-lmul is correct.

https://godbolt.org/z/nzfWE98n7

It does using e32m1 for vectorized codes:

vsetvli zero,a3,e32,m1,ta,ma
vfcvt.f.x.v v2,v1
vfcvt.rtz.x.f.v v2,v2
vse32.v v2,0(a5)

It definitely correct.

The reason you saw:
vsetvli a3,a4,e8,mf4,ta,ma

Plz note that this is not the vsetvl to configure the vectorized codes
operations.
It just a instruction calculating the elements to be processed for each
iterator.
It's generated by SELECT_VL pattern.
So, for SELECT_VL here,
vsetvli a3,a4,e8,mf4,ta,ma or vsetvli a3,a4,e32,m1,ta,ma are correct.
Since they are having same ratio.

More details on risc-v v spec.

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> So maybe
> ```
> (simplify
>  (cond (eq @0 INTEGER_CST@1) zero_p (plus@3 @0 INTEGER_CST@2))
>  @3
> )
> ```

Whoops I forgot the check `wi::to_wide(@1) == -wi::to_wide(@2)` there :).

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
>Note: this happens for all operators, not just addition!

Actually it is just addition with a constant on the trunk.
```
int g(int v, int b) {
if (v - b)
return v - b ;
else
return 0;
}
```
was handled with PR 19832.


I see division with a constant is not handled though:
```
int unopt(int v, int b) {
if (v /2)
return v / 2;
else
return 0;
}
```

[Bug target/112597] RISC-V regression testsuite errors with rv64gcv_zvl256b

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

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

--- Comment #7 from JuzheZhong  ---
I think there is middle-end issue here:

FAIL: gfortran.dg/maxval_char_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)

Could you file another PR CC me, Robin and Richard for this ?

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-11-21

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

We get in phiopt1:
v_2(D) == -8 ? 0 : _4
where _4 is defined as:
  _4 = v_2(D) + 8;

So maybe
```
(simplify
 (cond (eq @0 INTEGER_CST@1) zero_p (plus@3 @0 INTEGER_CST@2))
 @3
)
```


Note GCC handles already on the trunk:
```
int optb(int v, int b) {
if (v -b)
return v - b;
else
return 0;
}
int optc(int v, int b) {
if (v + b)
return v + b;
else
return 0;
}
```

[Bug middle-end/112660] New: missed-optimization: combine shifts when shifted out bits are known 0

[goon.pri.low at gmail dot com via Gcc-bugs]

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

Bug ID: 112660
   Summary: missed-optimization: combine shifts when shifted out
bits are known 0
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goon.pri.low at gmail dot com
  Target Milestone: ---

This function here we know the shifted out bits have to be 0:

int unopt(int v) {
if (v & 3) return -1;
return v >> 2 << 5;
}

unopt:
testdil, 3
jne .L3
sar edi, 2
mov eax, edi
sal eax, 5
ret
.L3:
mov eax, -1
ret

Therefore we could combine the shifts:

int opt(int v) {
if (v & 3) return -1;
return v << 3;
}

opt:
testdil, 3
jne .L7
lea eax, [0+rdi*8]
ret
.L7:
mov eax, -1
ret

[Bug rtl-optimization/112657] [13/14 Regression] missed optimization: cmove not used with multiple returns

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
  Known to fail||13.1.0
  Known to work||12.3.0
Summary|missed optimization: cmove  |[13/14 Regression] missed
   |not used with multiple  |optimization: cmove not
   |returns |used with multiple returns
   Target Milestone|--- |13.3

--- Comment #2 from Andrew Pinski  ---
The difference between GCC 12 and GCC 13 is:

GCC 13:
```
IF-THEN-JOIN block found, pass 1, test 2, then 3, join 4
```
GCC 12 and before:
```
IF-THEN-ELSE-JOIN block found, pass 1, test 2, then 3, else 4, join 5
```

Someone will have to debug ifcvt.cc to see why it fails on x86_64 but works on
aarch64.  Note there are some new changes to ifcvt.cc in review which might
improve this, though I am not sure.

[Bug tree-optimization/112659] New: missed-optimization: if (exp) return exp; else return 0;

[goon.pri.low at gmail dot com via Gcc-bugs]

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

Bug ID: 112659
   Summary: missed-optimization: if (exp) return exp; else return
0;
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goon.pri.low at gmail dot com
  Target Milestone: ---

This code here:

int unopt(int v) {
if (v + 8)
return v + 8;
else
return 0;
}

unopt:
xor edx, edx
lea eax, [rdi+8]
cmp edi, -8
cmove   eax, edx
ret

Could be optimized to:

int opt(int v) {
return v + 8;
}

opt:
lea eax, [rdi+8]
ret

Note: this happens for all operators, not just addition!
Also, have any suggestions for a better bug name? I am better at spotting
optimizations, not naming them.

[Bug target/112657] missed optimization: cmove not used with multiple returns

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-21

[Bug target/112657] missed optimization: cmove not used with multiple returns

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

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

--- Comment #1 from Andrew Pinski  ---
It is converted to a csel on aarch64 so it is either ifcvt.cc rejecting the
issue or a tuning issue with the x86_64 backend.

x86_64:
```
IF-THEN-JOIN block found, pass 1, test 2, then 3, join 4


== no more changes

1 possible IF blocks searched.
0 IF blocks converted.
0 true changes made.
```
vs aarch64:
```
IF-THEN-JOIN block found, pass 1, test 2, then 3, join 4
scanning new insn with uid = 30.
scanning new insn with uid = 31.
scanning new insn with uid = 32.
if-conversion succeeded through noce_try_cmove
...
```

[Bug c++/112658] New: ICE: finish_expr_stmt , at cp/semantics.cc:892

[julia.desmazes at gmail dot com via Gcc-bugs]

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

Bug ID: 112658
   Summary: ICE: finish_expr_stmt , at cp/semantics.cc:892
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: julia.desmazes at gmail dot com
  Target Milestone: ---

Created attachment 56664
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56664=edit
preprocessed file ( ii )

Hello,

I have come across an internal compiler error when using g++ 13.2.1.

The error occurs when casting a temporary array into a pointer and forwarding
the result to a constructor.

Code to reproduce : 
```
#include 
#include 
#include  

#define DEFAULT_DST_MAC ((uint8_t[6]) { 0xFC, 0xFC, 0x48, 0, 0, 0})

class foo{
public:
foo(const uint8_t new_mac[6]){
std::cout << new_mac << std::endl;  
memcpy(>mac, new_mac, 6);
}
private:
uint8_t mac[6];
};

int main(){
foo f((uint8_t*)DEFAULT_DST_MAC);
return 0;
}

```

Console log for `g++ -v -c main.cpp -freport-bug -save-temps` :

```
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230801 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-freport-bug' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/cc1plus -E -quiet -v -D_GNU_SOURCE
main.cpp -mtune=generic -march=x86-64 -freport-bug -fpch-preprocess -o main.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1

/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/x86_64-pc-linux-gnu

/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-c' '-freport-bug' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -version
-freport-bug -o main.s
GNU C++17 (GCC) version 13.2.1 20230801 (x86_64-pc-linux-gnu)
compiled by GNU C version 13.2.1 20230801, GMP version 6.3.0, MPFR
version 4.2.0-p12, MPC version 1.3.1, isl version isl-0.26-GMP

warning: MPFR header version 4.2.0-p12 differs from library version 4.2.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 5a490a353c29b926850bca65a518c219
main.cpp: In function ‘int main()’:
main.cpp:18:68: internal compiler error: in finish_expr_stmt, at
cp/semantics.cc:892
   18 | foo f((uint8_t*)DEFAULT_DST_MAC);
  |^
0x1ad33c8 internal_error(char const*, ...)
???:0
0x6b7b63 fancy_abort(char const*, int, char const*)
???:0
0x76527f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x9443d0 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccJZigsM.out file, please attach this to
your bugreport.
make: *** [makefile:10: main.o] Error 1
```

If needed, the `ccJZigsM.out` file can be found in the following git :
https://github.com/Essenceia/gcc_bug 

I will be happy to provide any additional files if needed.

Regards,

Julia Desmazes

[Bug middle-end/112653] We should optimize memmove to memcpy using alias oracle

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

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

--- Comment #3 from Jan Hubicka  ---
PR82898 testcases seems to be about type based alias analysis. However PTA
should be useable here.

[Bug tree-optimization/112657] New: missed optimization: cmove not used with multiple returns

[goon.pri.low at gmail dot com via Gcc-bugs]

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

Bug ID: 112657
   Summary: missed optimization: cmove not used with multiple
returns
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goon.pri.low at gmail dot com
  Target Milestone: ---

This function

int unopt(int c) {
if (c == 14)
return -9;
else
return c;
}

unopt:
mov eax, edi
cmp edi, 14
je  .L4
ret
.L4:
mov eax, -9
ret

Should probably be optimized to:

int opt(int c) {
if (c == 14)
c = -9;

return c;
}

opt:
cmp edi, 14
mov eax, -9
cmovne  eax, edi
ret

This seems to only really happen when negative numbers are used,

int positive(int c) {
if (c == 14)
return 9;
else
return c;
}

positive:
mov eax, edi
cmp edi, 14
mov edx, 9
cmove   eax, edx
ret

Though use of positive values still isn't completely optimized (possibly same
as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97968)

Also it seems like if the order is reversed:

int reverse(int c) {
if (c != 14)
c = 9120;

return c;
}

reverse:
cmp edi, 14
mov edx, 14
mov eax, 9120
cmove   eax, edx
ret

We could use %edi in the cmove and eliminate the 2nd instruction.

[Bug middle-end/112653] We should optimize memmove to memcpy using alias oracle

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

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

--- Comment #2 from Sam James  ---
See PR82898 especially...

[Bug middle-end/112653] We should optimize memmove to memcpy using alias oracle

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed, I had thought that this was recorded before too ...

[Bug debug/112656] btf: function prototypes generated with name

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

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

--- Comment #3 from Jose E. Marchesi  ---
clang does not emit BTF FUNC nor FUNC_PROTO entries for inlined functions.  So
the fix is probably to not emit CTF_K_FUNCTION entries that have not been
handled in the FOR_EACH_FUNCTION loop.

[Bug c++/112642] ranges::fold_left tries to access inactive union member of string in constant expression

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Miro Palmu from comment #5)
> If you use libstdc++ on clang these will not compile but with different
> errors.

The examples in comment 4 do compile using libstdc++ on clang, if you use
libstdc++ headers from after sept 29 (for trunk) or oct 21 (for gcc-13).

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

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

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

--- Comment #22 from CVS Commits  ---
The master branch has been updated by Robin Dapp :

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

commit r14-5697-g2bbc7f4ef6329df62146fd6d0da5f30750cc72b4
Author: Robin Dapp 
Date:   Tue Nov 21 12:51:12 2023 +0100

vect: Allow reduc_index != 1 for COND_OPs.

In PR112406 Tamar found another problem with COND_OP reductions.
I wrongly assumed that the reduction variable will always remain in
operand 1, just as we create the COND_OP in ifcvt.  But of course,
addition being commutative, we are free to swap operand 1 and 2 and we
end up with e.g.

 _ifc__60 = .COND_ADD (_2, _6, MADPictureC1_lsm.10_25,
MADPictureC1_lsm.10_25);

which does not pass the asserts I put in place.

This patch removes this restriction and allows the reduction index to be
2 as well.

gcc/ChangeLog:

PR middle-end/112406

* tree-vect-loop.cc (vectorize_fold_left_reduction): Allow
reduction index != 1.
(vect_transform_reduction): Handle reduction index != 1.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr112406-2.c: New test.

[Bug sanitizer/112562] [14 regression] asan_interceptors_memintrinsics.cpp doesn't assemble with Solaris/x86 as

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

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

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

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

commit r14-5693-gc7c1ee1cfdea228f79ba9d495b407f3689efc608
Author: Jakub Jelinek 
Date:   Tue Nov 21 21:01:48 2023 +0100

sanitizer: Fix build on SPARC/Solaris with Solaris as [PR112562]

Solaris as apparently doesn't accept %function and requires @function
instead.

This cherry-picks upstream commit.

2023-11-21  Jakub Jelinek  

PR sanitizer/112562
* sanitizer_common/sanitizer_asm.h: Cherry-pick llvm-project
revision
a855a16a02e76a0f4192c038bb64f3773947a2f7.
* interception/interception.h: Likewise.

[Bug target/112651] RISC-V Vector new option -mvect-lmul required to force LMUL values (rather than --param=riscv-autovec-lmul to hint at values)

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

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org

--- Comment #2 from Jorn Wolfgang Rennecke  ---
We can have in fact vector code without the intervention of the autovectorizer,
if the user uses GNU C to write explicitly vectorized code, which code
generation will simply translate to target instructions if the modes are
available.
Where the mode is too wide for the hardware becaue it doesn't support LMUL > 1,
we want the vector lowering to kick in.
I think we should achieve this aim by disabling vector modes altogether that
are too wide for the hardware.
That is alone is not a full solution, though, since a number of vector modes
can be obtained with more than one LMUL value.  Often, the higher LMUL values
appear to be more efficient when just counting instructions because they allow
vsetivli to be used for larger vectors, thus reducing the need to load
constants into general purpose registers first.

[Bug debug/112656] btf: function prototypes generated with name

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

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

--- Comment #2 from Jose E. Marchesi  ---
The btf_collect_datasec function in btf2out.cc traverses the cgraph and, for
each function, transforms its CTF_K_FUNCTION into a pair of BTF_KIND_FUNC_PROTO
and BTF_KIND_FUNC.  But if the function is inlined I don't think the
transformation is performed.  Thats probably why no BTF_KIND_FUNC is generated
for the function with inline enabled.

[Bug debug/112656] btf: function prototypes generated with name

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

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

--- Comment #1 from Jose E. Marchesi  ---
Smaller reproducer:

  static void log_event(const char *event_name, void *dev_ptr)
  {
  }

  void lala ()
  {
log_event ("foobar", ((void *)0));
  }

Note that the FUNC_PROTO for log_event seems to be created with a name only if
the function gets inlined:

$ bpf-unknown-none-gcc -gbtf -c -O2 foo.c -o foo.o
$ bpftool btf dump file foo.o
[1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
[3] FUNC_PROTO 'log_event' ret_type_id=1 vlen=2
'event_name' type_id=6
'dev_ptr' type_id=7
[4] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
[5] CONST '(anon)' type_id=4
[6] PTR '(anon)' type_id=5
[7] PTR '(anon)' type_id=0
[8] FUNC 'lala' type_id=2 linkage=global

$ bpf-unknown-none-gcc -gbtf -c -O2 -fno-inline foo.c -o foo.o
$ /usr/sbin/bpftool btf dump file foo.o
[1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
[3] FUNC_PROTO '(anon)' ret_type_id=1 vlen=2
'event_name' type_id=6
'dev_ptr' type_id=7
[4] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
[5] CONST '(anon)' type_id=4
[6] PTR '(anon)' type_id=5
[7] PTR '(anon)' type_id=0
[8] FUNC 'lala' type_id=2 linkage=global
[9] FUNC 'log_event' type_id=3 linkage=static

[Bug debug/112656] New: btf: function prototypes generated with name

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

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

Bug ID: 112656
   Summary: btf: function prototypes generated with name
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jemarch at gcc dot gnu.org
  Target Milestone: ---

BTF suports both BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO tags.  FUNC entries link
to their corresponding PROTO via type_id.  PROTO entries must have no names,
i.e. name_off shall be 0.

GCC seems to be generating non-anonymous BTF_KIND_FUNC_PROTO entries in some
circumstances:

$ bpf-unknown-none-gcc -c -O2 repro.i -o repro.o
$ bpftool btf dump all | grep FUNC_PROTO | grep -v anon
[8319] FUNC_PROTO 'kretprobe_ieee80211_get_channel_khz' ret_type_id=7
vlen=2
[8321] FUNC_PROTO 'kprobe_ieee80211_scan_completed' ret_type_id=7 vlen=2
[8333] FUNC_PROTO 'kprobe_ieee80211_request_scan' ret_type_id=7 vlen=2
[8343] FUNC_PROTO 'kprobe_unregister_netdev' ret_type_id=7 vlen=2
[8345] FUNC_PROTO 'kprobe_register_netdev' ret_type_id=7 vlen=2
[8347] FUNC_PROTO 'kprobe_ieee80211_unregister_hw' ret_type_id=7 vlen=1
[8349] FUNC_PROTO 'kprobe_ieee80211_register_hw' ret_type_id=7 vlen=1
[8351] FUNC_PROTO 'log_event' ret_type_id=0 vlen=2

[Bug target/112518] [14 Regression] wrong code with __builtin_mul_overflow_p() and int128_t on x86_64-pc-linux-gnu

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

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

--- Comment #9 from Sam James  ---
ack, np.

[Bug middle-end/112344] [14 Regression] Wrong code at -O2 on x86_64-pc-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug middle-end/112344] [14 Regression] Wrong code at -O2 on x86_64-pc-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Keywords|needs-bisection |
 Status|WAITING |NEW

--- Comment #6 from Jakub Jelinek  ---
Bisection shows this started with
r14-4089-gd45ddc2c04e471d0dcee016b6edacc00b8341b16
and still reproduces on latest trunk.
-fsanitize=undefined doesn't report anything.
Slightly cleaned up:
int
main ()
{
  long long b = 2036854775807LL;
  signed char c = 3;
  short d = 0;
  int e = -2147483647 - 1, f;
  for (f = 0; f < 7; f++)
while (e < 20)
  {
e += 2;
d = c -= b;
  }
  if (d != 13)
__builtin_abort ();
}

[Bug target/112518] [14 Regression] wrong code with __builtin_mul_overflow_p() and int128_t on x86_64-pc-linux-gnu

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

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

--- Comment #8 from Jakub Jelinek  ---
That one seems to be too large IMHO.

[Bug target/112518] [14 Regression] wrong code with __builtin_mul_overflow_p() and int128_t on x86_64-pc-linux-gnu

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

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

--- Comment #7 from Sam James  ---
We can add the test case at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112526#c14 too if it's fine.

[Bug target/112518] [14 Regression] wrong code with __builtin_mul_overflow_p() and int128_t on x86_64-pc-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
With -Os -mbmi2, it started for me with
r14-4968-g89e5d902fc55ad375f149f25a84c516ad360a606
and got fixed with
r14-5519-gf158bd511df1f55ebbbc0df3dee52c4400291984
So I'll just add it to the testsuite and we can close as dup of PR112526.

[Bug analyzer/112655] New: analyzer/infinite-loop.cc:75: Possible performance problem ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 112655
   Summary: analyzer/infinite-loop.cc:75: Possible performance
problem ?
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Static analyser cppcheck finds this problem:

analyzer/infinite-loop.cc:75:38: performance: Function parameter 'eedges'
should be passed by const reference. [passedByValue]

Source code is

struct infinite_loop
{
  infinite_loop (const exploded_node ,
location_t loc,
std::vector eedges,
logger *logger)

Some other potential problems found by cppcheck for the analyzer:

trunk.year/gcc/analyzer/sm-file.cc:282:3: performance: Variable 'm_unchecked'
is assigned in constructor body. Consider performing initialization in
initialization list. [useInitializationList]
trunk.year/gcc/analyzer/sm-sensitive.cc:170:3: performance: Variable
'm_sensitive' is assigned in constructor body. Consider performing
initialization in initialization list. [useInitializationList]
trunk.year/gcc/analyzer/sm-signal.cc:190:3: performance: Variable
'm_in_signal_handler' is assigned in constructor body. Consider performing
initialization in initialization list. [useInitializationList]
trunk.year/gcc/analyzer/sm-taint.cc:869:3: performance: Variable 'm_tainted' is
assigned in constructor body. Consider performing initialization in
initialization list. [useInitializationList]
trunk.year/gcc/analyzer/region-model.cc:6976:5: performance: Variable
'm_x_field' is assigned in constructor body. Consider performing initialization
in initialization list. [useInitializationList]
trunk.year/gcc/analyzer/varargs.cc:247:3: performance: Variable 'm_started' is
assigned in constructor body. Consider performing initialization in
initialization list. [useInitializationList]

[Bug target/112654] bpf: bpf program load failure

[brianwitte at mailfence dot com via Gcc-bugs]

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

Brian Witte  changed:

   What|Removed |Added

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

--- Comment #5 from Brian Witte  ---
My issue is now fixed.

As Jose said, the core issue was my kernel (Debian 6.5.10-1) needing the
-mcpu=v3 flag in order to properly compile for the bpf target.

Closing issue.

Thanks for the help!

[Bug middle-end/576] gcc performs invalid optimization with float operations when different rounding mode.

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #7 from Vincent Lefèvre  ---
(In reply to Andrew Pinski from comment #6)
> That is because the code is GNU C90 and not C++ .

I've used gcc, not g++. But this fails even with -std=gnu90.

[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs

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

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

--- Comment #1 from Jakub Jelinek  ---
Strange.  On cfarm211 which is
SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise
the test passes.
/export/home/jakub/gcc/gcc/testsuite/g++.dg/cpp26/literals2.C:7:9: warning:
multi-character character constant [-Wmultichar]
/export/home/jakub/gcc/gcc/testsuite/g++.dg/cpp26/literals2.C:8:9: warning:
multi-character character constant [-Wmultichar]
/export/home/jakub/gcc/gcc/testsuite/g++.dg/cpp26/literals2.C:10:9: error:
converting to execution character set: Illegal byte sequence
/export/home/jakub/gcc/gcc/testsuite/g++.dg/cpp26/literals2.C:11:9: error:
named universal character escapes are only valid in C++23
/export/home/jakub/gcc/gcc/testsuite/g++.dg/cpp26/literals2.C:11:9: error:
converting UCN to execution character set: Illegal byte sequence
/export/home/jakub/gcc/gcc/testsuite/g++.dg/cpp26/literals2.C:13:9: error:
converting UCN to execution character set: Illegal byte sequence
...
You get no diagnostics for those lines at all?  Buggy libconv?
I mean the emojis certainly aren't in ISO-8859-1...

[Bug c++/112619] [14 regression] ICE when building libcrafter (tree check: expected statement_list, have modify_expr in tsi_start, at tree-iterator.h:57) since r14-5086-gae07265381d934

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

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 56663
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56663=edit
gcc14-pr112619.patch

If it is ok for TRY_CATCH_EXPR to have second argument be something other than
STATEMENT_LIST, then this patch seems to work (and handles those cases like a
STATEMENT_LIST containing a single statement).

[Bug middle-end/576] gcc performs invalid optimization with float operations when different rounding mode.

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Vincent Lefèvre from comment #5)
> The -frounding-math option should solve the issue on this particular
> example. But on my machine, ld gives an "undefined reference to `_up'" error.

That is because the code is GNU C90 and not C++ .

[Bug middle-end/576] gcc performs invalid optimization with float operations when different rounding mode.

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #5 from Vincent Lefèvre  ---
The -frounding-math option should solve the issue on this particular example.
But on my machine, ld gives an "undefined reference to `_up'" error.

For a more general bug, see PR34678.

[Bug c++/112619] [14 regression] ICE when building libcrafter (tree check: expected statement_list, have modify_expr in tsi_start, at tree-iterator.h:57) since r14-5086-gae07265381d934

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
The created TRY_CATCH_EXPR certainly violates the try_catch_may_fallthrough
expectations, that the second operand of TRY_CATCH_EXPR is a STATEMENT_LIST,
which either a series of CATCH_EXPRs, or containing EH_FILTER_EXPR, or
statements
ending with RESX.  In this case the second operand is just MODIFY_EXPR.
So, shall we change try_catch_may_fallthrough to accept that as well and just
return false if second argument is not a STATEMENT_LIST, or handle such case as
if a single statement STATEMENT_LIST, something else?

[Bug testsuite/106120] [13 regression] g++.dg/warn/Wstringop-overflow-4.C fails since r13-1268-g8c99e307b20c50

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

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

--- Comment #11 from Hans-Peter Nilsson  ---
(In reply to Rainer Orth from comment #10)
> Since 20230106, this test produces an XPASS, according to gcc-testresults
> postings this happens everywhere:
> 
> +XPASS: g++.dg/warn/Wstringop-overflow-4.C  -std=gnu++98 pr106120 (test for
> bogus messages, line 144)
> 
> The corresponding line is
> 
>   T (S (2), new int16_t[r_imin_imax + 1]); // { dg-bogus "into a region of
> size" "pr106120" { xfail { c++98_only } } }
> 
> I think that xfail should just be removed?

Yes, though I think the date 20230106 is wrong (at least regarding the
"everywhere") and maybe a typo for 20231006, at least according to my own logs
- where I unsurprisingly don't track XPASS.  Gotta fix that.

[Bug c++/112642] ranges::fold_left tries to access inactive union member of string in constant expression

[miro.palmu at helsinki dot fi via Gcc-bugs]

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

--- Comment #5 from Miro Palmu  ---
I have been trying to figure out where exactly the bug is and these are my
findings.
> Or:
>
> #include 
>
> consteval void bar() {
> auto _ = [](std::string s) { return s; }({});
> }
>
> int main() {
>bar();
> }
>
> Or:
> 
> #include 
> constexpr auto foo(std::string init) { return init; }
> constexpr auto bar() { return foo("").size(); }
> constexpr auto i = bar();
>
>Clang compiles both of these without problems (it can't compile anything using 
>""s in a constant expression, maybe due to 
>https://github.com/llvm/llvm-project/issues/68527)
>
> So I am pretty sure this is a g++ front end bug.

If you use libstdc++ on clang these will not compile but with different errors.

Then with following example I try to showcase the bug without std::string.
Try it out: https://godbolt.org/z/rvoeMEaxc

This is bare minimum of  libstdc++ basic_string to reproduce this bug:

---

struct S {
union {
char a[1];
};
char* ptr; 
constexpr S() : ptr{a} {
a[0] = {};
}
constexpr S(S&&) = delete;
constexpr S(const S&) = delete;
constexpr S operator=(S&&) = delete;
constexpr S operator=(const S&) = delete;
constexpr ~S() = default;
}

---

Then to reproduce the bug instance of this class has to be function parameter
and the function has to be constant evaluated.
This can happens in std::basic_string move constructor bits/basic_string.h:682
and following tester functions tries to emulate what happens in it.

---

// Should always be false
constexpr bool test(const S& s){
return s.ptr != s.a;
}
consteval void tester1(S param = {}) { 
S notparam = {};
if (test(notparam)){
throw std::logic_error("compiletime notparam!");
}

if (test(param)) {
// gcc ends up here so fails to compile
// in std::basic_string move constructor
// compilation would fail due to accessing
// inactive union member
// clang and msvc never end up here

throw std::logic_error("compiletime param");
}
}

int main() { tester(); )

---

Notice that here only the parameter version fails.
In non-constant evaluated context (see godbolt link)
all of the test evaluate false as they should.

[Bug target/112599] RISC-V regression testsuite errors with rv64gcv_zvl1024b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #56626|0   |1
is obsolete||

--- Comment #2 from Patrick O'Neill  ---
Created attachment 56662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56662=edit
rv64gcv_zvl1024b testsuite failures 2023-11-21

Tested with hash 30d8188e6d1b450533ab0055b951ebfc75022219

Comparison with zvl128b (pr112583):

Resolved failures (present on zvl128b but not zvl1024b):
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++14  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++17  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++20  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++98  scan-tree-dump optimized
"return 15;"
XPASS: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
execution test
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
execution test
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
execution test
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
execution test
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
execution test
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
execution test

New failures (present on zvl1024b but not zvl128b):
FAIL: gfortran.dg/matmul_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/matmul_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/maxval_char_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/maxval_char_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/maxval_char_3.f90   -O3 -g  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/maxval_char_3.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/maxval_char_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/maxval_char_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/maxval_char_4.f90   -O3 -g  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/maxval_char_4.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/minlocval_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minlocval_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/minlocval_3.f90   -O3 -g  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minlocval_3.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/minval_char_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minval_char_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/minval_char_3.f90   -O3 -g  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minval_char_3.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/minval_char_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minval_char_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/minval_char_4.f90   -O3 -g  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minval_char_4.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_comp_12.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/proc_ptr_comp_12.f90   -O3 -g  execution test
FAIL: gcc.c-torture/execute/990128-1.c   -O2  execution test
FAIL: gcc.c-torture/execute/990128-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.c-torture/execute/990128-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  

[Bug target/112598] RISC-V regression testsuite errors with rv64gcv_zvl512b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #56625|0   |1
is obsolete||

--- Comment #4 from Patrick O'Neill  ---
Created attachment 56661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56661=edit
rv64gcv_zvl512b testsuite failures 2023-11-21

This report does not include the fix by Juzhe.
Tested with hash 30d8188e6d1b450533ab0055b951ebfc75022219

Comparison with zvl128b (pr112583):

Resolved failures (present on zvl128b but not zvl512b):
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++14  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++17  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++20  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++98  scan-tree-dump optimized
"return 15;"
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
execution test
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
execution test
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
execution test
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
execution test
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
execution test
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
execution test
XPASS: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"

New failures (present on zvl512b but not zvl128b):
FAIL: gfortran.dg/class_67.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/matmul_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/matmul_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/maxval_char_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/maxval_char_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/maxval_char_3.f90   -O3 -g  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/maxval_char_3.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/maxval_char_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/maxval_char_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/maxval_char_4.f90   -O3 -g  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/maxval_char_4.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/minval_char_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minval_char_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/minval_char_3.f90   -O3 -g  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minval_char_3.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/minval_char_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minval_char_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/minval_char_4.f90   -O3 -g  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minval_char_4.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_comp_12.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/proc_ptr_comp_12.f90   -O3 -g  execution test
FAIL: gcc.c-torture/compile/20090907-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error: in partial_subreg_p, at rtl.h:3187)
FAIL: gcc.c-torture/compile/20090907-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gcc.dg/no-strict-overflow-6.c scan-tree-dump optimized "return 0"
FAIL: gcc.dg/pr30957-1.c execution test
FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
FAIL: gcc.dg/torture/pr58955-2.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer 

[Bug target/112597] RISC-V regression testsuite errors with rv64gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #6 from Patrick O'Neill  ---
Whoops, got the author/committer mixed up. I meant to refer to Juzhe's fix.

[Bug target/112643] [14 regression] including x86intrin.h is broken for -march=native (which adds -mno-avx10.1-256 )

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

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

--- Comment #20 from Andrew Pinski  ---
The use of __builtin_ia32_2intersectd128 in avx512vp2intersectvlintrin.h has:
#pragma GCC target("avx512vp2intersect,avx512vl,no-evex512")

While i386-builtin.def does:
BDESC (0, OPTION_MASK_ISA2_AVX512VP2INTERSECT, CODE_FOR_nothing,
"__builtin_ia32_2intersectd128", IX86_BUILTIN_2INTERSECTD128, UNKNOWN, (int)
VOID_FTYPE_PUQI_PUQI_V4SI_V4SI)

[Bug target/112597] RISC-V regression testsuite errors with rv64gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #56624|0   |1
is obsolete||

--- Comment #5 from Patrick O'Neill  ---
Created attachment 56660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56660=edit
rv64gcv_zvl256b testsuite failures 2023-11-21

This report does not include the fix by Pan Li.
Tested with hash 30d8188e6d1b450533ab0055b951ebfc75022219

Comparison with zvl128b (pr112583):

Resolved failures (present on zvl128b but not zvl256b):
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++14  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++17  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++20  scan-tree-dump optimized
"return 15;"
XPASS: g++.dg/tree-ssa/pr83518.C  -std=gnu++98  scan-tree-dump optimized
"return 15;"

New failures (present on zvl256b but not zvl128b):
FAIL: gfortran.dg/class_67.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/matmul_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/matmul_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/maxval_char_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/maxval_char_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/maxval_char_3.f90   -O3 -g  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/maxval_char_3.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/maxval_char_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/maxval_char_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/maxval_char_4.f90   -O3 -g  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/maxval_char_4.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/minval_char_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minval_char_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/minval_char_3.f90   -O3 -g  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minval_char_3.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/minval_char_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minval_char_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/minval_char_4.f90   -O3 -g  (internal compiler error: in
duplicate_and_interleave, at tree-vect-slp.cc:8025)
FAIL: gfortran.dg/minval_char_4.f90   -O3 -g  (test for excess errors)
FAIL: gcc.dg/pr30957-1.c execution test
FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI 

[Bug sanitizer/112563] [14 regression] libsanitizer doesn't assemble with Solaris/sparc as

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

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

--- Comment #8 from Jakub Jelinek  ---
So, shall we go with
--- libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h.jj 
2023-11-15 12:45:17.359586776 +0100
+++ libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h 2023-11-21
18:29:52.401817763 +0100
@@ -15,7 +15,8 @@
 #define SANITIZER_REDEFINE_BUILTINS_H

 // The asm hack only works with GCC and Clang.
-#if !defined(_WIN32)
+// It doesn't work when using Solaris as either.
+#if !defined(_WIN32) && !SANITIZER_SOLARIS

 asm("memcpy = __sanitizer_internal_memcpy");
 asm("memmove = __sanitizer_internal_memmove");
@@ -50,7 +51,7 @@ using vector = Define_SANITIZER_COMMON_N
 }  // namespace std

 #  endif  // __cpluplus
-#endif// !_WIN32
+#endif// !_WIN32 && !SANITIZER_SOLARIS

 #  endif  // SANITIZER_REDEFINE_BUILTINS_H
 #endif// SANITIZER_COMMON_NO_REDEFINE_BUILTINS

then (either as local patch or try to push it upstream)?

[Bug target/112583] RISC-V regression testsuite errors with rv64gcv_zvl128b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #56615|0   |1
is obsolete||

--- Comment #6 from Patrick O'Neill  ---
Created attachment 56659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56659=edit
rv64gcv_zvl128b testsuite failures 2023-11-21

Failures here now match the failures with the default rv64gcv configuration.
Tested with hash 30d8188e6d1b450533ab0055b951ebfc75022219

[Bug target/112643] [14 regression] including x86intrin.h is broken for -march=native (which adds -mno-avx10.1-256 )

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|bootstrap   |target
   Keywords||rejects-valid
Summary|[14 regression] including   |[14 regression] including
   |x86intrin.h is broken for   |x86intrin.h is broken for
   |-march=native   |-march=native (which adds
   ||-mno-avx10.1-256 )

--- Comment #19 from Andrew Pinski  ---
`-march=native` will add `-mno-avx10.1-256` to the command line and that causes
the failure.

[Bug bootstrap/112643] [14 regression] including x86intrin.h is broken for -march=native

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[14 regression] failure to  |[14 regression] including
   |build libitm with   |x86intrin.h is broken for
   |--disable-bootstrap after   |-march=native
   |r14-5607-g2f8f7ee2db82a3|
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-21

--- Comment #18 from Andrew Pinski  ---
Ok, I am able to reproduce the issue now.
Simple testcase:
```
#include 
```

And then compile with `-march=native` and you will see the failure.

[Bug target/112654] bpf: bpf program load failure

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

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

--- Comment #4 from Jose E. Marchesi  ---
I think the problem here may be that OP's kernel doesn't understand BPF V4
instructions, and the program above has been compiled with them (movs).  Try to
use -mcpu=v3?

[Bug target/112654] bpf: bpf program load failure

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

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

--- Comment #3 from Jose E. Marchesi  ---
The instruction failing validation seems to be:

  e0:   bf a4 00 00 00 00 00 00 mov %r4,%r10

Which is a regular MOV instruction with zeroes in imm32 and offset16.  It has
SRC=X.  So I don't understand why the verifier is rejecting that instruction...

[Bug middle-end/110639] [OpenMP][5.1] Predefined firstprivate for pointers - attachment missing

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

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

--- Comment #2 from Tobias Burnus  ---
> If 'a' is already present on the device (e.g. 'omp target enter data 
> map(a)'), it works.

This applies to both the comment 0 example where only a section of 'a' is
mapped start > 0 and for the comment 1 example where the whole of 'a' is
mapped.

It also works fine if 'p' points inside 'A'.

* * *

As spec ref:

TR12 states in "14.8 target Construct" [379:8-10]:

"[C/C++] If a list item in a map clause has a base pointer that is
predetermined firstprivate (see Section 6.1.1) and on entry to the target
region the list item is mapped, the firstprivate pointer is updated via
corresponding base pointer initialization."


OpenMP 5.1 has in the mentioned C/C++-only section "2.21.7.2 Pointer
Initialization for Device Data Environments" that is too long to be quoted.


[The TR12 wording 'on entry to the target region' makes it clear that
effectively ordering needs to happen. The 5.1 wording is a bit unclear whether
it can be mapped with that very target construct - or the storage needs to be
present before the target directive. - However, the examples in OpenMP issue
#1796 implies that also 5.1 permit mapping the data and the pointer be on the
same directive.]

* * *

The implicit handling of the 'p' in this example happens in gimplify.cc's
gimplify_adjust_omp_clauses_1 for 'else if (code == OMP_CLAUSE_MAP && (flags &
GOVD_MAP_0LEN_ARRAY) != 0)'.

[Bug target/112654] bpf: bpf program load failure

[brianwitte at mailfence dot com via Gcc-bugs]

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

--- Comment #2 from Brian Witte  ---
$ ./pretty_uname.sh 
System Information
--
Kernel Name:   Linux
Node Name: debian
Kernel Release:6.5.0-4-amd64
Kernel Version:#1 SMP PREEMPT_DYNAMIC Debian 6.5.10-1 (2023-11-03)
Machine:   x86_64
Operating System:  GNU/Linux
Distribution:  Debian GNU/Linux

[Bug target/112654] bpf: bpf program load failure

[brianwitte at mailfence dot com via Gcc-bugs]

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

--- Comment #1 from Brian Witte  ---
Created attachment 56658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56658=edit
this is a *.tmp.s file

[Bug target/112654] New: bpf: bpf program load failure

[brianwitte at mailfence dot com via Gcc-bugs]

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

Bug ID: 112654
   Summary: bpf: bpf program load failure
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brianwitte at mailfence dot com
  Target Milestone: ---

This branch has of my bpf application can reproduce error.

  git clone -b gcc-bpf-backend-load-failure_2023-11-21
g...@git.sr.ht:~brianwitte/waldo-80211

  ./scripts/fetch_libraries.sh
  make
  make gcc-bpf # or make clang to compare
  sudo ./waldo_gcc-bpf

Toolchain commit hashes:
  $ cat current_working_toolchain/config 
  GCC_COMMIT_HASH=bc274b8d677212fbfc317d379acb02e0eef696a0
  BINUTILS_COMMIT_HASH=74affa1bc070ff0530b2a1b92d8d9fbcae6024ec


libbpf: prog 'kprobe_ieee80211_request_scan': -- BEGIN PROG LOAD LOG --
0: R1=ctx(off=0,imm=0) R10=fp0
0: (79) r0 = *(u64 *)(r1 +112); R0_w=scalar() R1=ctx(off=0,imm=0)
1: (15) if r0 == 0x0 goto pc+38   ; R0_w=scalar()
2: (b7) r2 = 42   ; R2_w=42
3: (18) r1 = 0x8cce3d293aaa   ;
R1_w=map_value(off=410,ks=4,vs=568,imm=0)
5: (62) *(u32 *)(r10 -12) = 15170 ; R10=fp0 fp-16=
6: (bf) r3 = r10  ; R3_w=fp0 R10=fp0
7: (07) r3 += -12 ; R3_w=fp-12
8: (85) call bpf_trace_printk#6   ; R0=scalar()
9: (85) call bpf_ktime_get_ns#5   ; R0_w=scalar()
10: (b7) r4 = 0   ; R4_w=0
11: (7b) *(u64 *)(r10 -8) = r0; R0_w=scalar() R10=fp0 fp-8_w=
12: (bf) r3 = r10 ; R3_w=fp0 R10=fp0
13: (bf) r2 = r10 ; R2_w=fp0 R10=fp0
14: (07) r3 += -8 ; R3_w=fp-8
15: (07) r2 += -12; R2_w=fp-12
16: (18) r1 = 0x8cce3d290c00  ; R1_w=map_ptr(off=0,ks=4,vs=8,imm=0)
18: (85) call bpf_map_update_elem#2   ; R0=scalar()
19: (bf) r4 = r0
BPF_MOV uses reserved fields
processed 18 insns (limit 100) max_states_per_insn 0 total_states 2
peak_states 2 mark_read 1
-- END PROG LOAD LOG --

bkz at debian in ~/src/waldo-80211 (gcc-bpf-backend-load-failure_2023-11-21●●)
$ $HOME/root-bpf/bin/bpf-unknown-none-objdump -d build_output/waldo.gcc.bpf.o

build_output/waldo.gcc.bpf.o: file format elf64-bpfle


Disassembly of section kprobe/ieee80211_register_hw:

 :
   0:   85 00 00 00 0e 00 00 00 call 14
   8:   b7 02 00 00 10 00 00 00 mov %r2,16
  10:   bf 06 00 00 00 00 00 00 mov %r6,%r0
  18:   bf a1 00 00 00 00 00 00 mov %r1,%r10
  20:   07 01 00 00 f0 ff ff ff add %r1,-16
  28:   85 00 00 00 10 00 00 00 call 16
  30:   18 05 00 00 00 00 00 00 lddw %r5,0
  38:   00 00 00 00 00 00 00 00
  40:   bf a4 00 00 00 00 00 00 mov %r4,%r10
  48:   bf 63 00 00 00 00 00 00 mov %r3,%r6
  50:   07 04 00 00 f0 ff ff ff add %r4,-16
  58:   77 03 00 00 20 00 00 00 rsh %r3,32
  60:   b7 02 00 00 22 00 00 00 mov %r2,34
  68:   18 01 00 00 e9 01 00 00 lddw %r1,489
  70:   00 00 00 00 00 00 00 00
  78:   85 00 00 00 06 00 00 00 call 6
  80:   b7 00 00 00 00 00 00 00 mov %r0,0
  88:   95 00 00 00 00 00 00 00 exit

Disassembly of section kprobe/ieee80211_unregister_hw:

 :
   0:   85 00 00 00 0e 00 00 00 call 14
   8:   b7 02 00 00 10 00 00 00 mov %r2,16
  10:   bf 06 00 00 00 00 00 00 mov %r6,%r0
  18:   bf a1 00 00 00 00 00 00 mov %r1,%r10
  20:   07 01 00 00 f0 ff ff ff add %r1,-16
  28:   85 00 00 00 10 00 00 00 call 16
  30:   18 05 00 00 16 00 00 00 lddw %r5,22
  38:   00 00 00 00 00 00 00 00
  40:   bf a4 00 00 00 00 00 00 mov %r4,%r10
  48:   bf 63 00 00 00 00 00 00 mov %r3,%r6
  50:   07 04 00 00 f0 ff ff ff add %r4,-16
  58:   77 03 00 00 20 00 00 00 rsh %r3,32
  60:   b7 02 00 00 22 00 00 00 mov %r2,34
  68:   18 01 00 00 e9 01 00 00 lddw %r1,489
  70:   00 00 00 00 00 00 00 00
  78:   85 00 00 00 06 00 00 00 call 6
  80:   b7 00 00 00 00 00 00 00 mov %r0,0
  88:   95 00 00 00 00 00 00 00 exit

Disassembly of section kprobe/register_netdev:

 :
   0:   79 17 70 00 00 00 00 00 ldxdw %r7,[%r1+112]
   8:   85 00 00 00 0e 00 00 00 call 14
  10:   c7 00 00 00 20 00 00 00 arsh %r0,32
  18:   bf a1 00 00 00 00 00 00 mov %r1,%r10
  20:   bf 06 00 00 00 00 00 00 mov %r6,%r0
  28:   b7 02 00 00 10 00 00 00 mov %r2,16
  30:   07 01 00 00 d0 ff ff ff add %r1,-48
  38:   85 00 00 00 10 00 00 00 call 16
  40:   15 07 11 00 00 00 00 00 jeq %r7,0,17
  48:   bf a0 00 00 00 00 00 00 mov %r0,%r10
  50:   18 01 00 00 2e 00 00 00 lddw %r1,46
  58:   00 00 00 00 00 00 00 00
  60:   07 00 00 00 d0 ff ff ff add %r0,-48
  68:   7b 1a 

[Bug target/112651] RISC-V Vector new option -mvect-lmul required to force LMUL values (rather than --param=riscv-autovec-lmul to hint at values)

[jeremy.bennett at embecosm dot com via Gcc-bugs]

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

Jeremy Bennett  changed:

   What|Removed |Added

Summary|RISC-V Vector   |RISC-V Vector new option
   |--param=riscv-autovec-lmul  |-mvect-lmul required to
   |should be -mvect-lmul   |force LMUL values (rather
   ||than
   ||--param=riscv-autovec-lmul
   ||to hint at values)

--- Comment #1 from Jeremy Bennett  ---
Updated, following the clarification in Bug 112648.

--param=riscv-autovec-lmul=

is intended as a hint to the optimizer, not as a mandate to only use a
particular LMUL value.

Therefore this bug covers an enhancement (-mvect-lmul) to support RISC-V Vector
processors which do not support all LMUL values.

It appears that the RISC-V vector standard requires all LMUL values to be
supported.  However the implementation of efficient LMUL != 1 on silicon is
very difficult leading at least one manufacturer to only support LMUL = 1.

As such this is an option, which should be default not be enabled, but should
be available where needed.