[Bug modula2/116378] [15 Regression] M2 bootstrap fails on x86_64-darwin after r15-2876

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

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

--- Comment #10 from Iain Sandoe  ---
(In reply to Gaius Mulley from comment #9)
> Created attachment 58934 [details]
> Proposed fix
> 
> Many thanks Iain and Andrew for your investigation and diagnosis, here is a
> patch based on your analysis:

works for me on a spot test on x86_64-darwin21 - test results 'nominal'.

Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]

[Kito Cheng via Gcc-bugs]

LGTM, thanks for fixing that :)

On Wed, Aug 14, 2024 at 2:06 PM 曾治金  wrote:
>
> This patch is to fix the bug (BugId:116305) introduced by the commit
> bd93ef for risc-v target.
>
> The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
> if TARGET_MIN_VLEN is larger than 128 in riscv_convert_vector_bits. So
> it changes the value of BYTES_PER_RISCV_VECTOR. For example, before
> merging the commit bd93ef and if TARGET_MIN_VLEN is 256, the value
> of BYTES_PER_RISCV_VECTOR should be [8, 8], but now [16, 16]. The value
> of riscv_bytes_per_vector_chunk and BYTES_PER_RISCV_VECTOR are no longer
> equal.
>
> Prologue will use BYTES_PER_RISCV_VECTOR.coeffs[1] to estimate the vlenb
> register value in riscv_legitimize_poly_move, and dwarf2cfi will also
> get the estimated vlenb register value in riscv_dwarf_poly_indeterminate_value
> to calculate the number of times to multiply the vlenb register value.
>
> So need to change the factor from riscv_bytes_per_vector_chunk to
> BYTES_PER_RISCV_VECTOR, otherwise we will get the incorrect dwarf
> information. The incorrect example as follow:
>
> ```
> csrrt0,vlenb
> sllit1,t0,1
> sub sp,sp,t1
>
> .cfi_escape 0xf,0xb,0x72,0,0x92,0xa2,0x38,0,0x34,0x1e,0x23,0x50,0x22
> ```
>
> The sequence '0x92,0xa2,0x38,0' means the vlenb register, '0x34' means
> the literal 4, '0x1e' means the multiply operation. But in fact, the
> vlenb register value just need to multiply the literal 2.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_dwarf_poly_indeterminate_value):
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/scalable_vector_cfi.c: New test.
>
> Signed-off-by: Zhijin Zeng 
> ---
>  gcc/config/riscv/riscv.cc |  4 +--
>  .../riscv/rvv/base/scalable_vector_cfi.c  | 32 +++
>  2 files changed, 34 insertions(+), 2 deletions(-)
>  create mode 100644 
> gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 5fe4273beb7..e740fc159dd 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -10773,12 +10773,12 @@ static unsigned int
>  riscv_dwarf_poly_indeterminate_value (unsigned int i, unsigned int *factor,
>   int *offset)
>  {
> -  /* Polynomial invariant 1 == (VLENB / riscv_bytes_per_vector_chunk) - 1.
> +  /* Polynomial invariant 1 == (VLENB / BYTES_PER_RISCV_VECTOR) - 1.
>   1. TARGET_MIN_VLEN == 32, polynomial invariant 1 == (VLENB / 4) - 1.
>   2. TARGET_MIN_VLEN > 32, polynomial invariant 1 == (VLENB / 8) - 1.
>*/
>gcc_assert (i == 1);
> -  *factor = riscv_bytes_per_vector_chunk;
> +  *factor = BYTES_PER_RISCV_VECTOR.coeffs[1];
>*offset = 1;
>return RISCV_DWARF_VLENB;
>  }
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
> new file mode 100644
> index 000..184da10caf3
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
> @@ -0,0 +1,32 @@
> +/* { dg-do compile } */
> +/* { dg-options "-g -O3 -march=rv64gcv -mabi=lp64d" } */
> +/* { dg-skip-if "" { *-*-* } {"-O2" "-O1" "-O0" "-Og" "-Oz" "-flto"} } */
> +/* { dg-final { scan-assembler {cfi_escape .*0x92,0xa2,0x38,0,0x32,0x1e} } } 
> */
> +
> +#include "riscv_vector.h"
> +
> +#define PI_2 1.570796326795
> +
> +extern void func(float *result);
> +
> +void test(const float *ys, const float *xs, float *result, size_t length) {
> +size_t gvl = __riscv_vsetvlmax_e32m2();
> +vfloat32m2_t vpi2 = __riscv_vfmv_v_f_f32m2(PI_2, gvl);
> +
> +for(size_t i = 0; i < length;) {
> +gvl = __riscv_vsetvl_e32m2(length - i);
> +vfloat32m2_t y = __riscv_vle32_v_f32m2(ys, gvl);
> +vfloat32m2_t x = __riscv_vle32_v_f32m2(xs, gvl);
> +vbool16_t mask0  = __riscv_vmflt_vv_f32m2_b16(x, y, gvl);
> +vfloat32m2_t fixpi = __riscv_vfrsub_vf_f32m2_mu(mask0, vpi2, vpi2, 
> 0, gvl);
> +
> +__riscv_vse32_v_f32m2(result, fixpi, gvl);
> +
> +func(result);
> +
> +i += gvl;
> +ys += gvl;
> +xs += gvl;
> +result += gvl;
> +}
> +}
> --
> 2.34.1
>
>
> This message and any attachment are confidential and may be privileged or 
> otherwise protected from disclosure. If you are not an intended recipient of 
> this message, please delete it and any attachment from your system and notify 
> the sender immediately by reply e-mail. Unintended recipients should not use, 
> copy, disclose or take any action based on this message or any information 
> contained in this message. Emails cannot be guaranteed to be secure or error 
> free as they can be intercepted, amended, lost or destroyed, and you should 
> take full responsibility for security checking.
>
> 本邮件及其任何附件具有保密性质，并可能受其他保护或不允许被披露给第三方。如阁下误收到本邮件，敬请立即以回复电子邮件的方式通知发件人，并将本邮件及其任何附件从阁下系统中予以删除。如阁下并非本邮件写明之收件人，敬请切勿使用、复制、披露本邮件或其任何内容，亦请切勿依

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

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Blah, adding popcountti2 does not work as the middle-end (in
> fold_builtin_bit_query) splits it into 2 __builtin_popcountll already ...

I have a patch for that:
```
diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index 0b902896ddd..b4d51eaeba5 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -10185,7 +10185,9 @@ fold_builtin_bit_query (location_t loc, enum
built_in_function fcode,
   tree call = NULL_TREE, tem;
   if (TYPE_PRECISION (arg0_type) == MAX_FIXED_MODE_SIZE
   && (TYPE_PRECISION (arg0_type)
- == 2 * TYPE_PRECISION (long_long_unsigned_type_node)))
+ == 2 * TYPE_PRECISION (long_long_unsigned_type_node))
+  /* If the target supports the optab, then don't do the expansion. */
+  && !direct_internal_fn_supported_p (ifn, arg0_type, OPTIMIZE_FOR_BOTH))
 {
   /* __int128 expansions using up to 2 long long builtins.  */
   arg0 = save_expr (arg0);

```

I didn't realize it was that simple :).

[Bug c++/113454] [14 regression] "assignment of read-only member" error with 483.xalancbmk from SPEC CPU 2006

[edison_chan_gz at hotmail dot com via Gcc-bugs]

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

edison  changed:

   What|Removed |Added

 CC||edison_chan_gz at hotmail dot 
com

--- Comment #3 from edison  ---
i can reproduct this error with cpu2006 483.xalancbmk and can not find any
workaround with gcc 14.1.

[Bug c++/110345] [C++26] P2552R3 - On the ignorability of standard attributes

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r15-2948-g2f90f3850eaf9d703d9eb63d5f0347158aa11027
Author: Jakub Jelinek 
Date:   Fri Aug 16 11:43:18 2024 +0200

c++: Pedwarn on [[]]; at class scope [PR110345]

For C++ 26 P2552R3 I went through all the spots (except modules) where
attribute-specifier-seq appears in the grammar and tried to construct
a testcase in all those spots, for now for [[deprecated]] attribute.

The fourth issue is that we just emit (when enabled) -Wextra-semi warning
not just for lone semicolon at class scope (correct), but also for
[[]]; or [[whatever]]; there too.
While just semicolon is valid in C++11 and newer,
https://eel.is/c++draft/class.mem#nt:member-declaration
allows empty-declaration, unlike namespace scope or block scope
something like attribute-declaration or empty statement with attributes
applied for it aren't supported.
While syntactically it matches
attribute-specifier-seq [opt] decl-specifier-seq [opt]
member-declarator-list [opt] ;
with the latter two omitted, there is
https://eel.is/c++draft/class.mem#general-3
which says that is not valid.

So, the following patch emits a pedwarn in that case.

2024-08-16  Jakub Jelinek  

PR c++/110345
* parser.cc (cp_parser_member_declaration): Call
maybe_warn_extra_semi
only if it is empty-declaration, if there are some tokens like
attribute, pedwarn that the declaration doesn't declare anything.

* g++.dg/cpp0x/gen-attrs-84.C: New test.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #171 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #170)
> (In reply to John Paul Adrian Glaubitz from comment #168)
> > I am getting a segmentation fault when building libgcc2.c now:
> > (...) 
> > Trying with gcc-15 now.
> 
> gcc-15 from July segfaults the same way when building libgcc2.c. Will try a
> gcc-15 snapshot from 7 August now.

I'm going to try to obtain a backtrace now. This may take a little while
though.

[Bug fortran/116388] New: [13/14/15 regression] Finalizer called on uninitialized components of intent(out) argument

[trnka at scm dot com via Gcc-bugs]

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

Bug ID: 116388
   Summary: [13/14/15 regression] Finalizer called on
uninitialized components of intent(out) argument
   Product: gcc
   Version: 13.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trnka at scm dot com
  Target Milestone: ---

Created attachment 58935
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58935&action=edit
testcase illustrating this issue

This feels potentially related to PR115070 but it is probably not an exact
duplicate; the proposed fix in PR115070 comment 9 does not fix this issue on
current master branch.

The attached testcase contains a type like this:

   type, public :: AType
  type(C_ptr) :: cptr = C_null_ptr
  logical :: cptr_invalid = .true.
  integer, allocatable :: x(:)
   contains
  final  :: FinalizerA
   end type
…
   impure elemental subroutine FinalizerA(self)
  type(AType), intent(inout) :: self

  if (.not. self%cptr_invalid) write(*,*) "A:", self%cptr
   end subroutine

Nothing in the program ever sets "cptr_invalid" to .false., so "A:" should
never be printed. However, compiling the testcase with gfortran 13.x and up
produces a program which often prints "A: somerandomvalue" once. Looking at the
tree dump, this is because the __final for CType creates a temporary
"comp_byte_stride", which is only partially initialized (so the components of
AType apart from x aren't initialized) but then calls FinalizerA on the whole a
component.

integer(kind=4) __final_finalizertestmodule_Ctype (struct array15_ctype &
restrict array, integer(kind=8) byte_stride, logical(kind=1) fini_coarray)
{
  struct btype comp_byte_stride;
…
  try
{
  comp_byte_stride.a.x.data = 0B;
  // no other components of comp_byte_stride are initialized here
…
  finally
{
  __builtin_free ((void *) strides);
  __builtin_free ((void *) sizes);
  desc.6.dtype = {.elem_len=80, .version=0, .rank=0, .type=5};
  desc.6.data = (void * restrict) &comp_byte_stride.a;
  desc.6.span = (integer(kind=8)) desc.6.dtype.elem_len;
  __final_finalizertestmodule_Atype (&desc.6, 80, 1);

Accessing uninitialized data at runtime is also confirmed using valgrind
--tool=memcheck.

"comp_byte_stride" was introduced by the following commit which went into 13.x.
GCC 12 and older seems to be unaffected by this issue.

commit d7caf313525a46f200d7f5db1ba893f853774aee
Author: Paul Thomas 
Date:   Sat Mar 18 07:56:23 2023 +

Fortran: Fix bugs and missing features in finalization [PR37336]

2023-03-18  Paul Thomas  

(BType in the testcase seems to be superfluous but removing it and putting
AType straight into CType masks the issue somewhat, because the uninitialized
data then happens to have the right value so that A: is never printed. However,
the bug still seems to be there in the tree dump even without BType.)

[Bug debug/87440] GCC creates debug that confuses gdb

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #5 from Bernd Edlinger  ---
This is only fixed for inlined subroutines with just one subrange,
but not for the case when a subroutine has multiple subranges,
as in this example:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/testsuite/gdb.cp/step-and-next-inline.cc;h=ac92206fd7f9036b909968b46355bdb8c6861ec3;hb=HEAD

$ gcc -g -O2 step-and-next-inline.cc

here the first invocation of "tree_check" has multiple subranges,
and a redundant lexical block:
 <2><865>: Abbrev Number: 41 (DW_TAG_inlined_subroutine)
<866>   DW_AT_abstract_origin: <0x955>
<86a>   DW_AT_entry_pc: 0x401165
<872>   DW_AT_GNU_entry_view: 0
<873>   DW_AT_ranges  : 0x21
<877>   DW_AT_call_file   : 1
<878>   DW_AT_call_line   : 52
<879>   DW_AT_call_column : 10
<87a>   DW_AT_sibling : <0x8b9>
 <3><87e>: Abbrev Number: 8 (DW_TAG_formal_parameter)
<87f>   DW_AT_abstract_origin: <0x966>
<883>   DW_AT_location: 0x37 (location list)
<887>   DW_AT_GNU_locviews: 0x35
 <3><88b>: Abbrev Number: 8 (DW_TAG_formal_parameter)
<88c>   DW_AT_abstract_origin: <0x96e>
<890>   DW_AT_location: 0x46 (location list)
<894>   DW_AT_GNU_locviews: 0x44
 <3><898>: Abbrev Number: 42 (DW_TAG_lexical_block)
<899>   DW_AT_ranges  : 0x21

while the other invocations look like:

 <2><8b9>: Abbrev Number: 44 (DW_TAG_inlined_subroutine)
<8ba>   DW_AT_abstract_origin: <0x955>
<8be>   DW_AT_entry_pc: 0x401177
<8c6>   DW_AT_GNU_entry_view: 0
<8c7>   DW_AT_low_pc  : 0x401177
<8cf>   DW_AT_high_pc : 0xa
<8d7>   DW_AT_call_file   : 1
<8d8>   DW_AT_call_line   : 53
<8d9>   DW_AT_call_column : 10
<8da>   DW_AT_sibling : <0x906>

... and happen to be fixed by :

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ac02e5b75451cc3c6ae9028338183bcdcb056ea2

This is not a big issue, but the duplicated variables
show up only while stepping thru the first invocation:

$ gdb a.out
[...]
Breakpoint 1, main () at step-and-next-inline.cc:64
64get_alias_set (&xx);  /* Beginning of main */
(gdb) s
get_alias_set (t=t@entry=0x404020 ) at step-and-next-inline.cc:51
51if (t != NULL
(gdb) s
52&& TREE_TYPE (t).z != 1
(gdb) s
tree_check (t=0x404020 , i=0) at step-and-next-inline.cc:40
40if (t->x != i)
(gdb) info locals
x = 
x = 
(gdb) 

I have a patch...

[Bug rtl-optimization/116372] [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

--- Comment #2 from Stefan Schulze Frielinghaus  
---
Finally a more manageable reproducer:

long x = -0x7fff - 1;
int main (void)
{
  long y = x % (-0xf - 1);
  if (-0x7fff - 1 + y == x == 0)
__builtin_abort ();
}

If compiled with -O1 -march=z13 and r15-2889 execution is successful and fails
with r15-2890 with r15-2903 manually applied on top.  I haven't looked much
into it but at least they deviate in ce1 where I see

if-conversion succeeded through noce_convert_multiple_sets

Of course, might be still a latent bug/something else.

[Bug rtl-optimization/116372] [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
Created attachment 58936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58936&action=edit
Dump from r15-2890

[Bug rtl-optimization/116372] [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
Created attachment 58937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58937&action=edit
Dump from r15-2890 with r15-2903

[Bug rtl-optimization/116372] [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
(In reply to Stefan Schulze Frielinghaus from comment #3)
> Created attachment 58936 [details]
> Dump from r15-2890

Ups, I actually meant "Dump from r15-2889" of course.

[Bug c++/116389] New: ICE in extract_constrain_insn for avrtiny and -O2

[dv at vollmann dot ch via Gcc-bugs]

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

Bug ID: 116389
   Summary: ICE in extract_constrain_insn for avrtiny and -O2
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dv at vollmann dot ch
  Target Milestone: ---
Target: avr

Created attachment 58938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58938&action=edit
Preprocessed source using -freport-bug

/ssd1/build/avr/gcc-bug/avr/avrtiny/libstdc++-v3/include/bits/locale_facets_nonio.tcc:578:7:
error: insn does not satisfy its constraints:
  578 |   }
  |   ^
(insn 180 900 181 27 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
(const_int 28 [0x1c])) [91 %sfp+28 S4 A8])
(reg:SI 30 r30))
"/ssd1/build/avr/gcc-bug/avr/avrtiny/libstdc++-v3/include/bits/locale_facets_nonio.tcc":477:14
119 {*movsi_split}
 (nil))
during RTL pass: postreload
/ssd1/build/avr/gcc-bug/avr/avrtiny/libstdc++-v3/include/bits/locale_facets_nonio.tcc:578:7:
internal compiler error: in extract_constrain_insn, at recog.cc:2783
0x1cf6290 internal_error(char const*, ...)
/ssd1/build/src/gcc/gcc/diagnostic-global-context.cc:491
0x6ea6b7 fancy_abort(char const*, int, char const*)
/ssd1/build/src/gcc/gcc/diagnostic.cc:1772
0x59b339 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/ssd1/build/src/gcc/gcc/rtl-error.cc:108
0x59b35f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/ssd1/build/src/gcc/gcc/rtl-error.cc:118
0x599e91 extract_constrain_insn(rtx_insn*)
/ssd1/build/src/gcc/gcc/recog.cc:2783
0xeeb2d6 reload_cse_simplify_operands
/ssd1/build/src/gcc/gcc/postreload.cc:396
0xeebe65 reload_cse_simplify
/ssd1/build/src/gcc/gcc/postreload.cc:179
0xeebe65 reload_cse_regs_1
/ssd1/build/src/gcc/gcc/postreload.cc:227
0xeedf9b reload_cse_regs
/ssd1/build/src/gcc/gcc/postreload.cc:65
0xeedf9b execute
/ssd1/build/src/gcc/gcc/postreload.cc:2366

This happens when trying to build libstdc++, the file is
libstdc++-v3/src/c++11/locale-inst.cc.
It only occurs for avrtiny and -O2, not for other AVR archs or other
optimization levels (Os, O1, O3 and O4 build fine).

[Bug modula2/116378] [15 Regression] M2 bootstrap fails on x86_64-darwin after r15-2876

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:9cdde72d1cefdf252ad2eec1ff465dccb3ab

commit r15-2949-g9cdde72d1cefdf252ad2eec1ff465dccb3ab
Author: Gaius Mulley 
Date:   Fri Aug 16 12:41:11 2024 +0100

PR modula2/116378 m2 bootstrap fails on x86_64-darwin

This patch fixes m2 bootstrap failure on x86_64-darwin.  libc_open
is defined with three parameters the last of which is an int for
portability (rather than a vararg).  This avoids portability
problems by promoting mode_t to an int.  In the future it could
be tidied up by using the m2 optarg extension.

gcc/m2/ChangeLog:

PR modula2/116378
* gm2-libs-iso/TermFile.mod (termOpen): Add third argument
for open.
* gm2-libs/libc.def (open): Remove vararg and use INTEGER for
mode parameter three.
* mc-boot-ch/Glibc.c (tracedb_open): Replace mode_t with int.
(libc_open): Rewrite without varargs.
* mc-boot/Glibc.h (libc_open): Replace varargs with int mode.
* pge-boot/Glibc.cc (libc_open): Rewrite.
* pge-boot/Glibc.h (libc_open): Replace varargs with int mode.

gcc/testsuite/ChangeLog:

PR modula2/116378
* gm2/extensions/run/pass/testopen.mod: Add third argument
for open.
* gm2/isolib/run/pass/openlibc.mod: Ditto.
* gm2/pim/run/pass/testaddr3.mod: Ditto.

Signed-off-by: Gaius Mulley 

[Bug c++/116390] New: Another ICE for avrtiny and optimization

[dv at vollmann dot ch via Gcc-bugs]

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

Bug ID: 116390
   Summary: Another ICE for avrtiny and optimization
   Product: gcc
   Version: 15.0
   URL: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dv at vollmann dot ch
  Target Milestone: ---
Target: avr

Created attachment 58939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58939&action=edit
Produced by -freport-bug

This ICE happened when I tried to strip down the source for
.

For -O3 and -O4 it produces an ICE very similar to #116389 (the file for O3 is
attached).
For -O2 it produces:
during RTL pass: final
ice.cc: In function 'void badFoo()':
ice.cc:70:1: internal compiler error: Segmentation fault
   70 | }
  | ^
0x1cf6290 internal_error(char const*, ...)
/ssd1/build/src/gcc/gcc/diagnostic-global-context.cc:491
0xfca7af crash_signal
/ssd1/build/src/gcc/gcc/toplev.cc:321
0x7ff7ade1d58f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xbf92e1 output_operand(rtx_def*, int)
/ssd1/build/src/gcc/gcc/final.cc:3624
0xbf9ee0 output_asm_insn(char const*, rtx_def**)
/ssd1/build/src/gcc/gcc/final.cc:3524
0x13e5557 output_movsisf(rtx_insn*, rtx_def**, int*)
/ssd1/build/src/gcc/gcc/config/avr/avr.cc:5923
0xbfd340 final_scan_insn_1
/ssd1/build/src/gcc/gcc/final.cc:2773
0xbfd908 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/ssd1/build/src/gcc/gcc/final.cc:2886
0xbfdb37 final_1
/ssd1/build/src/gcc/gcc/final.cc:1977
0xbfe634 rest_of_handle_final
/ssd1/build/src/gcc/gcc/final.cc:4239
0xbfe634 execute
/ssd1/build/src/gcc/gcc/final.cc:4317

and claims: "The bug is not reproducible, so it is likely a hardware or OS
problem." (which is bogus, it's 100% reproducible).

Due to this difference I submit this as separate bug, but feel free to mark it
as duplicate of #116389.

Here's the complete source for reference:

--- start source
struct MyStruct
{
int i;
};

void f_ic(int, char);
void f_pi(char const *, int);
void f_iic(int, int, char);

const MyStruct *f_rms();

char *f_rcp();
int f_ri();


void badFoo()
{
const MyStruct* ps = f_rms();
const char* pc = f_rcp();

unsigned n1 = f_rcp() - pc;

if (n1)
{
long n2 = n1 - ps->i;
if (n2 > 0)
{
if (f_ri())
n2 = n1;

if (f_ri())
{
f_iic(1, 2 * n2, ' ');
}
else
f_pi(pc, n2);
}
if (ps->i > 0)
{
if (n2 >= 0)
f_pi(pc + n2, ps->i);
else
{
f_ic(n2, ' ');
}
}

const int which = f_ri();
switch (which)
{
case 1:
if (f_ri())
f_rcp()[1] = ' ';
break;

case 2:
f_pi(f_rcp(), 1);
break;

case 3:
if (f_ri() && n1 < 0)
f_ic(n1, ' ');
else
f_rcp()[1] = ' ';
break;

}
}
}
--- end source

[Bug c++/115511] ICE on ambigous overload for _Float32

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #9 from dv at vollmann dot ch ---
Just asking: is there anything that's required from my side to close this as
fixed?

[Bug fortran/46371] [Coarray] [OOP] SELECT TYPE: scalar coarray variable is rejected

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org
 Status|NEW |WAITING
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #5 from Andre Vehreschild  ---
Patch proposed as:
https://gcc.gnu.org/pipermail/fortran/2024-August/060863.html

Waiting for review.

[Bug fortran/56496] [OOP] [F08] ICE with TYPE(*) coarray and SELECT TYPE

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||vehre at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #5 from Andre Vehreschild  ---
Covered by https://gcc.gnu.org/pipermail/fortran/2024-August/060863.html

Waiting for review.

[Bug c++/115511] ICE on ambigous overload for _Float32

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Fixed for 13.3+/14.2+/15.1+.

RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]

[Li, Pan2 via Gcc-bugs]

Hi there,

Please feel free to let me know if you don't have authority to commit it. I can 
help to commit this patch.

Pan


-Original Message-
From: Kito Cheng  
Sent: Friday, August 16, 2024 3:48 PM
To: 曾治金 
Cc: gcc-patc...@gcc.gnu.org; gcc-bugs@gcc.gnu.org
Subject: Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
[PR116305]

LGTM, thanks for fixing that :)

On Wed, Aug 14, 2024 at 2:06 PM 曾治金  wrote:
>
> This patch is to fix the bug (BugId:116305) introduced by the commit
> bd93ef for risc-v target.
>
> The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
> if TARGET_MIN_VLEN is larger than 128 in riscv_convert_vector_bits. So
> it changes the value of BYTES_PER_RISCV_VECTOR. For example, before
> merging the commit bd93ef and if TARGET_MIN_VLEN is 256, the value
> of BYTES_PER_RISCV_VECTOR should be [8, 8], but now [16, 16]. The value
> of riscv_bytes_per_vector_chunk and BYTES_PER_RISCV_VECTOR are no longer
> equal.
>
> Prologue will use BYTES_PER_RISCV_VECTOR.coeffs[1] to estimate the vlenb
> register value in riscv_legitimize_poly_move, and dwarf2cfi will also
> get the estimated vlenb register value in riscv_dwarf_poly_indeterminate_value
> to calculate the number of times to multiply the vlenb register value.
>
> So need to change the factor from riscv_bytes_per_vector_chunk to
> BYTES_PER_RISCV_VECTOR, otherwise we will get the incorrect dwarf
> information. The incorrect example as follow:
>
> ```
> csrrt0,vlenb
> sllit1,t0,1
> sub sp,sp,t1
>
> .cfi_escape 0xf,0xb,0x72,0,0x92,0xa2,0x38,0,0x34,0x1e,0x23,0x50,0x22
> ```
>
> The sequence '0x92,0xa2,0x38,0' means the vlenb register, '0x34' means
> the literal 4, '0x1e' means the multiply operation. But in fact, the
> vlenb register value just need to multiply the literal 2.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_dwarf_poly_indeterminate_value):
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/scalable_vector_cfi.c: New test.
>
> Signed-off-by: Zhijin Zeng 
> ---
>  gcc/config/riscv/riscv.cc |  4 +--
>  .../riscv/rvv/base/scalable_vector_cfi.c  | 32 +++
>  2 files changed, 34 insertions(+), 2 deletions(-)
>  create mode 100644 
> gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 5fe4273beb7..e740fc159dd 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -10773,12 +10773,12 @@ static unsigned int
>  riscv_dwarf_poly_indeterminate_value (unsigned int i, unsigned int *factor,
>   int *offset)
>  {
> -  /* Polynomial invariant 1 == (VLENB / riscv_bytes_per_vector_chunk) - 1.
> +  /* Polynomial invariant 1 == (VLENB / BYTES_PER_RISCV_VECTOR) - 1.
>   1. TARGET_MIN_VLEN == 32, polynomial invariant 1 == (VLENB / 4) - 1.
>   2. TARGET_MIN_VLEN > 32, polynomial invariant 1 == (VLENB / 8) - 1.
>*/
>gcc_assert (i == 1);
> -  *factor = riscv_bytes_per_vector_chunk;
> +  *factor = BYTES_PER_RISCV_VECTOR.coeffs[1];
>*offset = 1;
>return RISCV_DWARF_VLENB;
>  }
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
> new file mode 100644
> index 000..184da10caf3
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
> @@ -0,0 +1,32 @@
> +/* { dg-do compile } */
> +/* { dg-options "-g -O3 -march=rv64gcv -mabi=lp64d" } */
> +/* { dg-skip-if "" { *-*-* } {"-O2" "-O1" "-O0" "-Og" "-Oz" "-flto"} } */
> +/* { dg-final { scan-assembler {cfi_escape .*0x92,0xa2,0x38,0,0x32,0x1e} } } 
> */
> +
> +#include "riscv_vector.h"
> +
> +#define PI_2 1.570796326795
> +
> +extern void func(float *result);
> +
> +void test(const float *ys, const float *xs, float *result, size_t length) {
> +size_t gvl = __riscv_vsetvlmax_e32m2();
> +vfloat32m2_t vpi2 = __riscv_vfmv_v_f_f32m2(PI_2, gvl);
> +
> +for(size_t i = 0; i < length;) {
> +gvl = __riscv_vsetvl_e32m2(length - i);
> +vfloat32m2_t y = __riscv_vle32_v_f32m2(ys, gvl);
> +vfloat32m2_t x = __riscv_vle32_v_f32m2(xs, gvl);
> +vbool16_t mask0  = __riscv_vmflt_vv_f32m2_b16(x, y, gvl);
> +vfloat32m2_t fixpi = __riscv_vfrsub_vf_f32m2_mu(mask0, vpi2, vpi2, 
> 0, gvl);
> +
> +__riscv_vse32_v_f32m2(result, fixpi, gvl);
> +
> +func(result);
> +
> +i += gvl;
> +ys += gvl;
> +xs += gvl;
> +result += gvl;
> +}
> +}
> --
> 2.34.1
>
>
> This message and any attachment are confidential and may be privileged or 
> otherwise protected from disclosure. If you are not an intended recipient of 
> this message, please delete it and any attachment from your system and notify 
> the sender immediately by reply e-mail. Unintended recipients should not use, 
> copy, disclose or take any action based on this message or any 

Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]

[Zhijin Zeng]

Hi Pan,
I am a new guy for GCC and don't have authority to commit. Please help to 
commit this patch. Thank you very much.
Zhijin

> From: "Li, Pan2"
> Date:  Fri, Aug 16, 2024, 20:15
> Subject:  RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
> [PR116305]
> To: "曾治金"
> Cc: "gcc-patc...@gcc.gnu.org", 
> "gcc-bugs@gcc.gnu.org", "Kito 
> Cheng"
> Hi there,
> 
> Please feel free to let me know if you don't have authority to commit it. I 
> can help to commit this patch.
> 
> Pan
> 
> 
> -Original Message-
> From: Kito Cheng  
> Sent: Friday, August 16, 2024 3:48 PM
> To: 曾治金 
> Cc: gcc-patc...@gcc.gnu.org; gcc-bugs@gcc.gnu.org
> Subject: Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
> [PR116305]
> 
> LGTM, thanks for fixing that :)
> 
> On Wed, Aug 14, 2024 at 2:06 PM 曾治金  wrote:
> >
> > This patch is to fix the bug (BugId:116305) introduced by the commit
> > bd93ef for risc-v target.
> >
> > The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
> > if TARGET_MIN_VLEN is larger than 128 in riscv_convert_vector_bits. So
> > it changes the value of BYTES_PER_RISCV_VECTOR. For example, before
> > merging the commit bd93ef and if TARGET_MIN_VLEN is 256, the value
> > of BYTES_PER_RISCV_VECTOR should be [8, 8], but now [16, 16]. The value
> > of riscv_bytes_per_vector_chunk and BYTES_PER_RISCV_VECTOR are no longer
> > equal.
> >
> > Prologue will use BYTES_PER_RISCV_VECTOR.coeffs[1] to estimate the vlenb
> > register value in riscv_legitimize_poly_move, and dwarf2cfi will also
> > get the estimated vlenb register value in 
> > riscv_dwarf_poly_indeterminate_value
> > to calculate the number of times to multiply the vlenb register value.
> >
> > So need to change the factor from riscv_bytes_per_vector_chunk to
> > BYTES_PER_RISCV_VECTOR, otherwise we will get the incorrect dwarf
> > information. The incorrect example as follow:
> >
> > ```
> > csrr    t0,vlenb
> > slli    t1,t0,1
> > sub     sp,sp,t1
> >
> > .cfi_escape 0xf,0xb,0x72,0,0x92,0xa2,0x38,0,0x34,0x1e,0x23,0x50,0x22
> > ```
> >
> > The sequence '0x92,0xa2,0x38,0' means the vlenb register, '0x34' means
> > the literal 4, '0x1e' means the multiply operation. But in fact, the
> > vlenb register value just need to multiply the literal 2.
> >
> > gcc/ChangeLog:
> >
> >         * config/riscv/riscv.cc (riscv_dwarf_poly_indeterminate_value):
> >
> > gcc/testsuite/ChangeLog:
> >
> >         * gcc.target/riscv/rvv/base/scalable_vector_cfi.c: New test.
> >
> > Signed-off-by: Zhijin Zeng 
> > ---
> >  gcc/config/riscv/riscv.cc                     |  4 +--
> >  .../riscv/rvv/base/scalable_vector_cfi.c      | 32 +++
> >  2 files changed, 34 insertions(+), 2 deletions(-)
> >  create mode 100644 
> >gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
> >
> > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> > index 5fe4273beb7..e740fc159dd 100644
> > --- a/gcc/config/riscv/riscv.cc
> > +++ b/gcc/config/riscv/riscv.cc
> > @@ -10773,12 +10773,12 @@ static unsigned int
> >  riscv_dwarf_poly_indeterminate_value (unsigned int i, unsigned int *factor,
> >                                       int *offset)
> >  {
> > -  /* Polynomial invariant 1 == (VLENB / riscv_bytes_per_vector_chunk) - 1.
> > +  /* Polynomial invariant 1 == (VLENB / BYTES_PER_RISCV_VECTOR) - 1.
> >       1. TARGET_MIN_VLEN == 32, polynomial invariant 1 == (VLENB / 4) - 1.
> >       2. TARGET_MIN_VLEN > 32, polynomial invariant 1 == (VLENB / 8) - 1.
> >    */
> >    gcc_assert (i == 1);
> > -  *factor = riscv_bytes_per_vector_chunk;
> > +  *factor = BYTES_PER_RISCV_VECTOR.coeffs[1];
> >    *offset = 1;
> >    return RISCV_DWARF_VLENB;
> >  }
> > diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c 
> > b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
> > new file mode 100644
> > index 000..184da10caf3
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
> > @@ -0,0 +1,32 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-g -O3 -march=rv64gcv -mabi=lp64d" } */
> > +/* { dg-skip-if "" { *-*-* } {"-O2" "-O1" "-O0" "-Og" "-Oz" "-flto"} } */
> > +/* { dg-final { scan-assembler {cfi_escape .*0x92,0xa2,0x38,0,0x32,0x1e} } 
> > } */
> > +
> > +#include "riscv_vector.h"
> > +
> > +#define PI_2 1.570796326795
> > +
> > +extern void func(float *result);
> > +
> > +void test(const float *ys, const float *xs, float *result, size_t length) {
> > +    size_t gvl = __riscv_vsetvlmax_e32m2();
> > +    vfloat32m2_t vpi2 = __riscv_vfmv_v_f_f32m2(PI_2, gvl);
> > +
> > +    for(size_t i = 0; i < length;) {
> > +        gvl = __riscv_vsetvl_e32m2(length - i);
> > +        vfloat32m2_t y = __riscv_vle32_v_f32m2(ys, gvl);
> > +        vfloat32m2_t x = __riscv_vle32_v_f32m2(xs, gvl);
> > +        vbool16_t mask0  = __riscv_vmflt_vv_f32m2_b16(x, y, gvl);
> > +        vfloat32m2_t fixpi = __riscv_vfrsub_vf_f32m2_mu(mask0, vpi2, vpi2, 
> > 0, gvl

[Bug fortran/86468] [12/13/14/15 regression][Coarray] ICE verify_gimple failed

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

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

Andre Vehreschild  changed:

   What|Removed |Added

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

RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]

[Li, Pan2 via Gcc-bugs]

Is this you newest version?
https://patchwork.sourceware.org/project/gcc/patch/8fd4328940034d8778cca67eaad54e5a2c2b1a6c.1c2f51e1.0a9a.4367.9762.9b6eccc3b...@feishu.cn/

If so, you may need to rebase upstream, I got conflict when git am.

Applying: RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]
error: corrupt patch at line 20
Patch failed at 0001 RISC-V: Fix factor in dwarf_poly_indeterminate_value 
[PR116305]
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Pan

-Original Message-
From: Zhijin Zeng  
Sent: Friday, August 16, 2024 8:47 PM
To: Li, Pan2 
Cc: gcc-patc...@gcc.gnu.org; gcc-bugs@gcc.gnu.org; Kito Cheng 

Subject: Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
[PR116305]

Hi Pan,
I am a new guy for GCC and don't have authority to commit. Please help to 
commit this patch. Thank you very much.
Zhijin

> From: "Li, Pan2"
> Date:  Fri, Aug 16, 2024, 20:15
> Subject:  RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
> [PR116305]
> To: "曾治金"
> Cc: "gcc-patc...@gcc.gnu.org", 
> "gcc-bugs@gcc.gnu.org", "Kito 
> Cheng"
> Hi there,
> 
> Please feel free to let me know if you don't have authority to commit it. I 
> can help to commit this patch.
> 
> Pan
> 
> 
> -Original Message-
> From: Kito Cheng  
> Sent: Friday, August 16, 2024 3:48 PM
> To: 曾治金 
> Cc: gcc-patc...@gcc.gnu.org; gcc-bugs@gcc.gnu.org
> Subject: Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
> [PR116305]
> 
> LGTM, thanks for fixing that :)
> 
> On Wed, Aug 14, 2024 at 2:06 PM 曾治金  wrote:
> >
> > This patch is to fix the bug (BugId:116305) introduced by the commit
> > bd93ef for risc-v target.
> >
> > The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
> > if TARGET_MIN_VLEN is larger than 128 in riscv_convert_vector_bits. So
> > it changes the value of BYTES_PER_RISCV_VECTOR. For example, before
> > merging the commit bd93ef and if TARGET_MIN_VLEN is 256, the value
> > of BYTES_PER_RISCV_VECTOR should be [8, 8], but now [16, 16]. The value
> > of riscv_bytes_per_vector_chunk and BYTES_PER_RISCV_VECTOR are no longer
> > equal.
> >
> > Prologue will use BYTES_PER_RISCV_VECTOR.coeffs[1] to estimate the vlenb
> > register value in riscv_legitimize_poly_move, and dwarf2cfi will also
> > get the estimated vlenb register value in 
> > riscv_dwarf_poly_indeterminate_value
> > to calculate the number of times to multiply the vlenb register value.
> >
> > So need to change the factor from riscv_bytes_per_vector_chunk to
> > BYTES_PER_RISCV_VECTOR, otherwise we will get the incorrect dwarf
> > information. The incorrect example as follow:
> >
> > ```
> > csrr    t0,vlenb
> > slli    t1,t0,1
> > sub     sp,sp,t1
> >
> > .cfi_escape 0xf,0xb,0x72,0,0x92,0xa2,0x38,0,0x34,0x1e,0x23,0x50,0x22
> > ```
> >
> > The sequence '0x92,0xa2,0x38,0' means the vlenb register, '0x34' means
> > the literal 4, '0x1e' means the multiply operation. But in fact, the
> > vlenb register value just need to multiply the literal 2.
> >
> > gcc/ChangeLog:
> >
> >         * config/riscv/riscv.cc (riscv_dwarf_poly_indeterminate_value):
> >
> > gcc/testsuite/ChangeLog:
> >
> >         * gcc.target/riscv/rvv/base/scalable_vector_cfi.c: New test.
> >
> > Signed-off-by: Zhijin Zeng 
> > ---
> >  gcc/config/riscv/riscv.cc                     |  4 +--
> >  .../riscv/rvv/base/scalable_vector_cfi.c      | 32 +++
> >  2 files changed, 34 insertions(+), 2 deletions(-)
> >  create mode 100644 
> >gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
> >
> > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> > index 5fe4273beb7..e740fc159dd 100644
> > --- a/gcc/config/riscv/riscv.cc
> > +++ b/gcc/config/riscv/riscv.cc
> > @@ -10773,12 +10773,12 @@ static unsigned int
> >  riscv_dwarf_poly_indeterminate_value (unsigned int i, unsigned int *factor,
> >                                       int *offset)
> >  {
> > -  /* Polynomial invariant 1 == (VLENB / riscv_bytes_per_vector_chunk) - 1.
> > +  /* Polynomial invariant 1 == (VLENB / BYTES_PER_RISCV_VECTOR) - 1.
> >       1. TARGET_MIN_VLEN == 32, polynomial invariant 1 == (VLENB / 4) - 1.
> >       2. TARGET_MIN_VLEN > 32, polynomial invariant 1 == (VLENB / 8) - 1.
> >    */
> >    gcc_assert (i == 1);
> > -  *factor = riscv_bytes_per_vector_chunk;
> > +  *factor = BYTES_PER_RISCV_VECTOR.coeffs[1];
> >    *offset = 1;
> >    return RISCV_DWARF_VLENB;
> >  }
> > diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c 
> > b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
> > new file mode 100644
> > index 000..184da10caf3
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
> > @@ -0,0 +1,32 @@
> > +/* { dg-do

Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]

[Zhijin Zeng]

Sorry, the line number changed. The newest version as follow,

This patch is to fix the bug (BugId:116305) introduced by the commit
bd93ef for risc-v target.

The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
if TARGET_MIN_VLEN is larger than 128 in riscv_convert_vector_bits. So
it changes the value of BYTES_PER_RISCV_VECTOR. For example, before
merging the commit bd93ef and if TARGET_MIN_VLEN is 256, the value
of BYTES_PER_RISCV_VECTOR should be [8, 8], but now [16, 16]. The value
of riscv_bytes_per_vector_chunk and BYTES_PER_RISCV_VECTOR are no longer
equal.

Prologue will use BYTES_PER_RISCV_VECTOR.coeffs[1] to estimate the vlenb
register value in riscv_legitimize_poly_move, and dwarf2cfi will also
get the estimated vlenb register value in riscv_dwarf_poly_indeterminate_value
to calculate the number of times to multiply the vlenb register value.

So need to change the factor from riscv_bytes_per_vector_chunk to
BYTES_PER_RISCV_VECTOR, otherwise we will get the incorrect dwarf
information. The incorrect example as follow:

```
csrr    t0,vlenb
slli    t1,t0,1
sub     sp,sp,t1

.cfi_escape 0xf,0xb,0x72,0,0x92,0xa2,0x38,0,0x34,0x1e,0x23,0x50,0x22
```

The sequence '0x92,0xa2,0x38,0' means the vlenb register, '0x34' means
the literal 4, '0x1e' means the multiply operation. But in fact, the
vlenb register value just need to multiply the literal 2.

gcc/ChangeLog:

        * config/riscv/riscv.cc (riscv_dwarf_poly_indeterminate_value):

gcc/testsuite/ChangeLog:

        * gcc.target/riscv/rvv/base/scalable_vector_cfi.c: New test.

Signed-off-by: Zhijin Zeng 
---
 gcc/config/riscv/riscv.cc                     |  4 +--
 .../riscv/rvv/base/scalable_vector_cfi.c      | 32 +++
 2 files changed, 34 insertions(+), 2 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 1f60d8f9711..8b7123e043e 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -11010,12 +11010,12 @@ static unsigned int
 riscv_dwarf_poly_indeterminate_value (unsigned int i, unsigned int *factor,
                                      int *offset)
 {
-  /* Polynomial invariant 1 == (VLENB / riscv_bytes_per_vector_chunk) - 1.
+  /* Polynomial invariant 1 == (VLENB / BYTES_PER_RISCV_VECTOR) - 1.
      1. TARGET_MIN_VLEN == 32, polynomial invariant 1 == (VLENB / 4) - 1.
      2. TARGET_MIN_VLEN > 32, polynomial invariant 1 == (VLENB / 8) - 1.
   */
   gcc_assert (i == 1);
-  *factor = riscv_bytes_per_vector_chunk;
+  *factor = BYTES_PER_RISCV_VECTOR.coeffs[1];
   *offset = 1;
   return RISCV_DWARF_VLENB;
 }
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
new file mode 100644
index 000..184da10caf3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-g -O3 -march=rv64gcv -mabi=lp64d" } */
+/* { dg-skip-if "" { *-*-* } {"-O2" "-O1" "-O0" "-Og" "-Oz" "-flto"} } */
+/* { dg-final { scan-assembler {cfi_escape .*0x92,0xa2,0x38,0,0x32,0x1e} } } */
+
+#include "riscv_vector.h"
+
+#define PI_2 1.570796326795
+
+extern void func(float *result);
+
+void test(const float *ys, const float *xs, float *result, size_t length) {
+    size_t gvl = __riscv_vsetvlmax_e32m2();
+    vfloat32m2_t vpi2 = __riscv_vfmv_v_f_f32m2(PI_2, gvl);
+
+    for(size_t i = 0; i < length;) {
+        gvl = __riscv_vsetvl_e32m2(length - i);
+        vfloat32m2_t y = __riscv_vle32_v_f32m2(ys, gvl);
+        vfloat32m2_t x = __riscv_vle32_v_f32m2(xs, gvl);
+        vbool16_t mask0  = __riscv_vmflt_vv_f32m2_b16(x, y, gvl);
+        vfloat32m2_t fixpi = __riscv_vfrsub_vf_f32m2_mu(mask0, vpi2, vpi2, 0, 
gvl);
+
+        __riscv_vse32_v_f32m2(result, fixpi, gvl);
+
+        func(result);
+
+        i += gvl;
+        ys += gvl;
+        xs += gvl;
+        result += gvl;
+    }
+}
--
2.34.1

> From: "Li, Pan2"
> Date:  Fri, Aug 16, 2024, 21:05
> Subject:  RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
> [PR116305]
> To: "Zhijin Zeng"
> Cc: "gcc-patc...@gcc.gnu.org", 
> "gcc-bugs@gcc.gnu.org", "Kito 
> Cheng"
> Is this you newest version?
> https://patchwork.sourceware.org/project/gcc/patch/8fd4328940034d8778cca67eaad54e5a2c2b1a6c.1c2f51e1.0a9a.4367.9762.9b6eccc3b...@feishu.cn/
> 
> If so, you may need to rebase upstream, I got conflict when git am.
> 
> Applying: RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]
> error: corrupt patch at line 20
> Patch failed at 0001 RISC-V: Fix factor in dwarf_poly_indeterminate_value 
> [PR116305]
> hint: Use 'git am --show-current-patch=diff' to see the failed patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
> 
> P

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #172 from John Paul Adrian Glaubitz  ---
Interesting, it's showing an illegal instruction now:

root@tirpitz:..sh4-linux-gnu/libgcc>
/srv/gcc-snapshot-3YBWb3/gcc-snapshot-20240715/build/./gcc/xgcc
-B/srv/gcc-snapshot-3YBWb3/gcc-snapshot-20240715/build/./gcc/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/sys-include   -fno-checking -g -O2 -O2  -g
-O2 -DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -fpic -DNO_FPSCR_VALUES -w
-Wno-sync-nand -I. -I. -I../.././gcc -I../../../src/libgcc
-I../../../src/libgcc/. -I../../../src/libgcc/../gcc
-I../../../src/libgcc/../include  -DHAVE_CC_TLS   -o _muldi3.o -MT _muldi3.o
-MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../src/libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
during GIMPLE pass: waccess
../../../src/libgcc/libgcc2.c: In function '__muldi3':
../../../src/libgcc/libgcc2.c:538:1: internal compiler error: Segmentation
fault
  538 | }
  | ^

../../../src/libgcc/libgcc2.c:538:1: internal compiler error: Illegal
instruction
root@tirpitz:..sh4-linux-gnu/libgcc>

Could this be just an issue of the compiler generating invalid code?

[Bug c++/116384] [14/15 Regression] ICE in convert_nontype_argument, at cp/pt.cc:7877

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug target/116391] New: Emit spellcheck suggestions for __arm_rsr and __arm_wsr intrinsics

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

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

Bug ID: 116391
   Summary: Emit spellcheck suggestions for __arm_rsr and
__arm_wsr intrinsics
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

GCC 14 added intrinsics to read and write to sysregs, allowing the user to
avoid inline assembly. It also has validation code to ensure the user passes a
legit register.

One way this can be made even more user-friendly is to use the spell-check
infrastructure to add hints when the user passes an invalid sysreg name. We
already do this for -mcpu/march options and we could do the same here.
We could get aarch64.cc::aarch64_init_sysregs to initialise a vector of
candidates as well, maybe multiple such vectors split by whether a reg is
read/write.

Then we could utilise the candidates_list_and_hint API to get a recommendation
for a misspelled register.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #173 from John Paul Adrian Glaubitz  ---
Here's what I got from gdb:

(gdb) bt
#0  0x0109fee4 in wi::add_large(long long*, long long const*, unsigned int,
long long const*, unsigned int, unsigned int, signop, wi::overflow_type*) ()
#1  0x00bdbc10 in
access_ref::add_offset(generic_wide_int > const&,
generic_wide_int > const&) ()
#2  0x00bdd0e8 in compute_objsize_r(tree_node*, gimple*, bool, int,
access_ref*, ssa_name_limit_t&, pointer_query*) ()
#3  0x in ?? ()
(gdb) display/i $pc
1: x/i $pc
=> 0x109fee4 <_ZN2wi9add_largeEPxPKxjS2_jj6signopPNS_13overflow_typeE+84>: 
mov.l   @r2,r3
(gdb) x/wx $r2
0x7c07eaa0: Cannot access memory at address 0x7c07eaa0
(gdb)

[Bug target/114607] aarch64: Incorrect expansion of svsudot

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Sandiford
:

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

commit r12-10673-g2d1b1f404f3361a0e3d9d2a2bee5cf68c1290fe5
Author: Richard Sandiford 
Date:   Fri Aug 16 15:37:50 2024 +0100

aarch64: Fix expansion of svsudot [PR114607]

Not sure how this happend, but: svsudot is supposed to be expanded
as USDOT with the operands swapped.  However, a thinko in the
expansion of svsudot meant that the arguments weren't in fact
swapped; the attempted swap was just a no-op.  And the testcases
blithely accepted that.

gcc/
PR target/114607
* config/aarch64/aarch64-sve-builtins-base.cc
(svusdot_impl::expand): Fix botched attempt to swap the operands
for svsudot.

gcc/testsuite/
PR target/114607
* gcc.target/aarch64/sve/acle/asm/sudot_s32.c: New test.

(cherry picked from commit 2c1c2485a4b1aca746ac693041e51ea6da5c64ca)

[Bug target/114603] aarch64: Invalid SVE cnot optimisation

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Sandiford
:

https://gcc.gnu.org/g:33b11c6d9a600fac25b7cc714e9905aac049685b

commit r12-10674-g33b11c6d9a600fac25b7cc714e9905aac049685b
Author: Richard Sandiford 
Date:   Fri Aug 16 15:37:50 2024 +0100

aarch64: Fix bogus cnot optimisation [PR114603]

aarch64-sve.md had a pattern that combined:

cmpeq   pb.T, pa/z, zc.T, #0
mov zd.T, pb/z, #1

into:

cnotzd.T, pa/m, zc.T

But this is only valid if pa.T is a ptrue.  In other cases, the
original would set inactive elements of zd.T to 0, whereas the
combined form would copy elements from zc.T.

gcc/
PR target/114603
* config/aarch64/aarch64-sve.md (@aarch64_pred_cnot): Replace
with...
(@aarch64_ptrue_cnot): ...this, requiring operand 1 to be
a ptrue.
(*cnot): Require operand 1 to be a ptrue.
* config/aarch64/aarch64-sve-builtins-base.cc
(svcnot_impl::expand):
Use aarch64_ptrue_cnot for _x operations that are predicated
with a ptrue.  Represent other _x operations as fully-defined _m
operations.

gcc/testsuite/
PR target/114603
* gcc.target/aarch64/sve/acle/general/cnot_1.c: New test.

(cherry picked from commit 67cbb1c638d6ab3a9cb77e674541e2b291fb67df)

[Bug target/114607] aarch64: Incorrect expansion of svsudot

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

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

Richard Sandiford  changed:

   What|Removed |Added

  Known to work||12.4.1, 13.3.1, 14.1.0,
   ||15.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Richard Sandiford  ---
Fixed on all active branches.

[Bug target/114603] aarch64: Invalid SVE cnot optimisation

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

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

Richard Sandiford  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to work||12.4.1, 13.3.1, 15.0

--- Comment #6 from Richard Sandiford  ---
Fixed on all active branches.

[Bug other/116392] New: RFE: capture inlining information in SARIF output

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

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

Bug ID: 116392
   Summary: RFE: capture inlining information in SARIF output
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: SARIF
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Similar to RFE 116300 (which is for macro expansions), our textual output can
report inlining information for middle-end warnings, but our SARIF output
doesn't yet capture that.

AFAIK SARIF doesn't yet have a way of expressing this, but it could probably be
done via a new kind of location relationship.

An example can be seen in gcc/testsuite/gcc.dg/Wnonnull.c in our testsuite:
  https://godbolt.org/z/3o1ehYf7b
which has e.g.:

In function 'my_strcpy',
inlined from 'my_strcpy' at :20:1,
inlined from 'test' at :40:5:
:27:7: warning: argument 2 null where non-null expected [-Wnonnull]
   27 |   memcpy (dst, src, size - 1);  /* { dg-warning "argument 2 null
where non-null expected" } */
  |   ^~~
: In function 'test':
:7:14: note: in a call to function 'memcpy' declared 'nonnull'
7 | extern void *memcpy (void *__restrict __dest, const void *__restrict
__src,
  |  ^~

SARIF output for the same is here:
  https://godbolt.org/z/9W5M7Gd31

where the SARIF corresponding to the above currently has just:

{"ruleId": "-Wnonnull",
 "level": "warning",
 "message": {"text": "argument 2 null where non-null expected"},
 "locations": [{"physicalLocation": {"artifactLocation": {"uri": ""},
 "region": {"startLine": 27,
"startColumn": 7,
"endColumn": 34},
 "contextRegion": {"startLine": 27,
   "snippet": {"text": "   
  memcpy (dst, src, size - 1);  /* { dg-warning \"argument 2 null where
non-null expected\" } */\n"}}},
"logicalLocations": [{"name": "test",
  "fullyQualifiedName": "test",
  "decoratedName": "test",
  "kind": "function"}]}],
 "relatedLocations": [{"physicalLocation": {"artifactLocation": {"uri":
""},
"region": {"startLine": 7,
   "startColumn": 14,
   "endColumn": 20},
"contextRegion": {"startLine": 7,
  "snippet":
{"text": "extern void *memcpy (void *__restrict __dest, const void *__restrict
__src,\n"}}},
   "message": {"text": "in a call to function 'memcpy'
declared 'nonnull'"}}]}]}]}

which is missing all that inlining info.

[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls

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

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

Torbjorn SVENSSON  changed:

   What|Removed |Added

 CC||azoff at gcc dot gnu.org

--- Comment #20 from Torbjorn SVENSSON  ---
The g++.dg/torture/pr101373.C test case XPASS on arm-none-eabi for Cortex-M.

Does this line make sense in embedded context?
// { dg-xfail-run-if "PR100409" { *-*-* } }


If I run the test case on x86_64-pc-linux-gnu, it SIGSEGV on the nullptr
dereference, i.e. the throw statement in foo() is ignored. Is this correct?

On arm-non-eabi, the result depends on how the memory space is defined, but
generally speaking, reading address 0 does not cause the application to abort.
Most Cortex-M targets, that I've come across, have the initial $SP value
defined at address 0 and the entry point defined at address 4.

How can this test case be update to reflect that it sometimes is expected to
XFAIL and sometimes to PASS?

[Bug target/116030] ICE "could not split insn" in final_scan_insn_1, at final.cc on power pc

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

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-08-16
 Ever confirmed|0   |1
 CC||bergner at gcc dot gnu.org,
   ||guihaoc at gcc dot gnu.org,
   ||linkw at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #1 from Peter Bergner  ---
Confirmed, although on my native build, I had to add either -mcpu=power8 or
-mcpu=power7.  It passes for me for -mcpu=power6 or earlier and
-mcpu={power9,power10}.

Haochen, this isn't related (fixed?) by some of your recent patches dealing
with const vector 0 sources, is it?

[Bug target/85624] ICE when initializing array that is 128-byte aligned

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Georg-Johann Lay
:

https://gcc.gnu.org/g:507b4e147588c0fafe952b7226dd764ebeebb103

commit r14-10595-g507b4e147588c0fafe952b7226dd764ebeebb103
Author: Georg-Johann Lay 
Date:   Fri Aug 16 18:13:34 2024 +0200

AVR: target/85624 - Use HImode for clrmemqi alignment.

gcc/
PR target/85624
* config/avr/avr.md (*clrmemqi*): Use HImode for alignment operand.

gcc/testsuite/
* gcc.target/avr/torture/pr85624.c: New test.

[Bug fortran/114146] REPEATABLE argument of RANDOM_INIT and repeated execution of the program

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:07ece73d4712c68144a07681b24a8c1f963256ab

commit r15-2955-g07ece73d4712c68144a07681b24a8c1f963256ab
Author: Harald Anlauf 
Date:   Thu Aug 15 22:31:11 2024 +0200

Fortran: fix documentation of intrinsic RANDOM_INIT [PR114146]

gcc/fortran/ChangeLog:

PR fortran/114146
* intrinsic.texi: Fix documentation of arguments of RANDOM_INIT,
which is conforming to the F2018 standard.

[Bug target/116391] Emit spellcheck suggestions for __arm_rsr and __arm_wsr intrinsics

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-08-16

--- Comment #1 from Andrew Pinski  ---
Confirmed.
An example is:
```
#include 

void f()
{
__arm_rsr64 ("iadr_el1");
__arm_rsr64 ("aidr_el1");
}
```

The second is the correct spelling. Note clang ICEs on the invalid names :).

[Bug rtl-optimization/116372] [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-08-16

--- Comment #6 from Andrew Pinski  ---
.

[Bug rtl-optimization/116372] [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 CC||pinskia at gcc dot gnu.org
   Keywords||wrong-code

[Bug target/85624] ICE when initializing array that is 128-byte aligned

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Georg-Johann Lay :

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

commit r15-2956-gc8981bde45d365330a5e7c2e33c8dbaf3495248a
Author: Georg-Johann Lay 
Date:   Fri Aug 16 18:13:34 2024 +0200

AVR: target/85624 - Use HImode for clrmemqi alignment.

gcc/
PR target/85624
* config/avr/avr.md (*clrmemqi*): Use HImode for alignment operand.

(cherry picked from commit 507b4e147588c0fafe952b7226dd764ebeebb103)

[Bug target/85624] ICE when initializing array that is 128-byte aligned

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|15.0|14.3

--- Comment #7 from Georg-Johann Lay  ---
Fixed in v14.3+

[Bug c/116393] New: -fpie discards -fpic

[stsp at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 116393
   Summary: -fpie discards -fpic
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

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

Attached is a small test-case.
Just run make:
```
cc -fpic -fpie   -c -o weak.o weak.c
cc -shared -o liba.so weak.o
/usr/bin/ld: weak.o: warning: relocation against `sym' in read-only section
`.text'
/usr/bin/ld: weak.o: relocation R_X86_64_PC32 against symbol `sym' can not be
used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make: *** [makefile:6: liba.so] Error 1
```

It asks for -fpic, which is already there.
Surprisingly, removing -fpie makes it to build.

[Bug driver/116393] -fpie discards -fpic

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||documentation
 Ever confirmed|0   |1
   Last reconfirmed||2024-08-16
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
pic and pie are override each other.

PIC/PIE is a 3 way state:
* nothing (both -fno-pie and -fno-pic)
* PIC
* PIE



The documentation seems like it should be improved here with that respect
though.

[Bug driver/116393] documentation does not mention that PIE over rides PIC

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #2 from Stas Sergeev  ---
Can -fpic win, rather than to rely on a
command line args order, which is very fragile?

[Bug driver/116393] documentation does not mention that PIE over rides PIC

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Stas Sergeev from comment #2)
> Can -fpic win, rather than to rely on a
> command line args order, which is very fragile?

No because that part is documented.

[Bug driver/116393] documentation does not mention that PIE over rides PIC

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Stas Sergeev from comment #2)
> > Can -fpic win, rather than to rely on a
> > command line args order, which is very fragile?
> 
> No because that part is documented.

Oh and it would break backwards compatability. That is why I said this is just
a documentation issue rather than anything else.

[Bug driver/116393] documentation does not mention that PIE over rides PIC

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #5 from Stas Sergeev  ---
The documentation says:
When this flag is set, the macros __pic__ and __PIC__ are defined to 1.

I checked and I get these defines with no -fpic and with
"-fpic -fpie" which supposedly discards -fpic. The only way
to get these undefined, is -fno-pic.
So these macros do not match the reality.

[Bug driver/116393] documentation does not mention that PIE over rides PIC

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug middle-end/70419] descriptions of -fpic/-fPIC and -fpic/-fPIE aren't clear and contain syntax error

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||stsp at users dot 
sourceforge.net

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

[Bug middle-end/70419] descriptions of -fpic/-fPIC and -fpic/-fPIE aren't clear and contain syntax error

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-08-16
 Status|UNCONFIRMED |NEW

--- Comment #5 from Andrew Pinski  ---
Also add that the -fPIC/-fPIE is a 3 state option which is not mentioned
either. The last one wins.

[Bug fortran/116394] New: Memory leaks in compute_dot_product

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

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

Bug ID: 116394
   Summary: Memory leaks in compute_dot_product
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Just looked at simplify.cc:compute_dot_product, and this has

  case BT_COMPLEX:
if (conj_a && a->ts.type == BT_COMPLEX)
  c = gfc_simplify_conjg (a);
else
  c = gfc_copy_expr (a);
result = gfc_add (result, gfc_multiply (c, gfc_copy_expr (b)));
break;

which leaks memory.

[Bug driver/116393] documentation does not mention that PIE over rides PIC

[stsp at users dot sourceforge.net via Gcc-bugs]

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

Stas Sergeev  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--- Comment #7 from Stas Sergeev  ---
Well but __pic__ and __PIC__ do not behave as documented.
They are not undefined by adding -fpie, so your explanation
does not suit (or there is some other bug).

[Bug fortran/116394] Memory leaks in compute_dot_product

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

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Koenig  ---
No, it does not :-)

[Bug middle-end/70419] descriptions of -fpic/-fPIC and -fpic/-fPIE aren't clear and contain syntax error

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

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

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

[Bug driver/116393] documentation does not mention that PIE over rides PIC

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #8 from Andrew Pinski  ---
Still a dup. The documentation needs to be improved for sure for both
-fpic/-fpie and PR 70419 is tracking that.

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

[Bug target/107757] PPCLE: Inefficient vector constant creation

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

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

--- Comment #4 from Michael Meissner  ---
Note, this code only shows up when the target CPU is power8.

For the following code:

vector long long lsb64()
{
   return vec_splats(1LL);
}

Both power9 and power10 generate:

xxspltib 34,1
vextsb2d 2,2

Now, if you want to add code for power8, you would:

1) Add code in rs6000.c's easy_altivec_constant (and possibly vsplitis_shifted
and other functions) to handle the operation on power8.

2) Then add the code in rs6000.c's gen_easy_altivec_constant to generate the
insns for this.  You might need to add explicit insns in altivec.md or vsx.md
for this optimization.

[Bug c/116395] New: -m32 forbids empty scalar initializer

[stsp at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 116395
   Summary: -m32 forbids empty scalar initializer
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

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

$ gunzip a.c.gz
$ gcc -c a.c
[ no output ]
$ gcc -m32 -c a.c
doprnt.c: In function ‘_doprnt’:
doprnt.c:144:27: error: empty scalar initializer
  144 |   va_list to_be_printed = {};/* argument to be printed if
numeric specifier are used */
  |   ^
doprnt.c:144:27: note: (near initialization for ‘to_be_printed’)


I tried the trivial test-cases, but they pass.
But in this particular file any empty scalar initializers
are forbidden with -m32.

[Bug c/116396] New: __pic__ and __PIC__ are controlled by -fpie

[stsp at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 116396
   Summary: __pic__ and __PIC__ are controlled by -fpie
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

Maybe this is a documentation issue.
Documentation says:

-fpic:
When this flag is set, the macros __pic__ and __PIC__ are defined to 1.

It doesn't say anything about these macros in -fpie section.
But:
-fpie sets them to 1
- neither -fpic nor -fpie presence in cmdline, gives 2
-fno-pie undefines them

[Bug c/116395] -m32 forbids empty scalar initializer

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
va_list can't be used that way.
in x86 (32bit) va_list is a pointer while in x86_64, it is an array.

[Bug c/116395] -m32 forbids empty scalar initializer

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

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

--- Comment #2 from Andrew Pinski  ---
va_list can only be assigned to via another va_list, initialized using va_start
or va_copy.

[Bug middle-end/70419] descriptions of -fpic/-fPIC and -fpic/-fPIE aren't clear and contain syntax error

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

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

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

[Bug c/116396] __pic__ and __PIC__ are controlled by -fpie

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Again this is a dup of bug 70419 which mentions this issue too.

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

[Bug c/116395] -m32 forbids empty scalar initializer

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #3 from Stas Sergeev  ---
(In reply to Andrew Pinski from comment #1)
> va_list can't be used that way.
> in x86 (32bit) va_list is a pointer while in x86_64, it is an array.

https://stackoverflow.com/questions/77647307/expression-int-a-why-a-is-null
So isn't the {} an universal initializer that can
be used on pointers too? The above article says it is...

[Bug c/116395] -m32 forbids empty scalar initializer

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Stas Sergeev from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > va_list can't be used that way.
> > in x86 (32bit) va_list is a pointer while in x86_64, it is an array.
> 
> https://stackoverflow.com/questions/77647307/expression-int-a-why-a-is-null
> So isn't the {} an universal initializer that can
> be used on pointers too? The above article says it is...

Yes it was not supported in GCC 11 as such as GCC 11 didn't have this support
from C23, it was add in GCC 13.

[Bug c/116395] -m32 forbids empty scalar initializer

[stsp at users dot sourceforge.net via Gcc-bugs]

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

Stas Sergeev  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #5 from Stas Sergeev  ---
Thank you.
Then its not INVALID, but rather is FIXED.

[Bug c/116395] -m32 forbids empty scalar initializer

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #6 from Andrew Pinski  ---
It is invalid since it is not being backported ...

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #9 from Andrew Pinski  ---
The two patches submitted for this:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660664.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660665.html

[Bug tree-optimization/115373] [15 Regression] RISCV slp-cond-2-big-array.c slp-cond-2.c scan-tree-dump fails since r15-859-geaaa4b88038

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-08-16
 Blocks||53947
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Component|target  |tree-optimization
   See Also||https://linaro.atlassian.ne
   ||t/browse/GNU-1222


Referenced Bugs:

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

[Bug testsuite/116397] New: [15 Regression] slp-reduc-3.c fails on aarch64-linux-gnu

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

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

Bug ID: 116397
   Summary: [15 Regression] slp-reduc-3.c fails on
aarch64-linux-gnu
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

>From https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652829.html:

On aarch64 and arm there's

FAIL: gcc.dg/vect/slp-reduc-3.c scan-tree-dump-times vect "VEC_PERM_EXPR"
0

which is a testism, I _think_ due to a bogus vect_load_lanes check
in that line.  The code is as expected not using a SLP reduction of
two lanes due to the widen-sum pattern used.  It might be that we
somehow fail to use load-lanes when vectorizing the load with SLP
which means that for SLP reductions we fail to consider
load-lanes as override.  I think we should leave this FAIL, we need to
work to get load-lanes vectorization from SLP anyway.  To fix this
the load-permutation followup I have in the works will be necessary.

[Bug testsuite/116397] [15 Regression] slp-reduc-3.c fails on aarch64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug rtl-optimization/114522] [15 regression] gcc.target/arm/aes_xor_combine.c scan-assembler-not veor fails after r14-9692-g839bc42772ba7a

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-08-16
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
This one still fails:
FAIL: gcc.target/aarch64/aes_xor_combine.c scan-assembler-not eor
FAIL: gcc.target/aarch64/aes_xor_combine.c scan-assembler-not mov

[Bug rtl-optimization/114522] [15 regression] gcc.target/arm/aes_xor_combine.c scan-assembler-not veor fails after r14-9692-g839bc42772ba7a

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

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

--- Comment #4 from Andrew Pinski  ---
The function in aes_xor_combine.c which fails is:

```
#include 

#define AESE(r, v, key) (r = vaeseq_u8 ((v), (key)));
#define AESD(r, v, key) (r = vaesdq_u8 ((v), (key)));

const uint8x16_t zero = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};

uint8x16_t foo1 (uint8x16_t a, uint8x16_t b)
{
  uint8x16_t dummy;
  AESE(dummy, a ^ b, zero);
  AESE(dummy, dummy ^ a, zero);
  return dummy;
}
```

Compile with `-O3 -mcpu=cortex-a55+aes`.
What we have in this case is:
```
(insn 7 4 8 2 (set (reg:V16QI 107 [ _1 ])
(xor:V16QI (reg/v:V16QI 105 [ aD.22791 ])
(reg/v:V16QI 106 [ bD.22792 ]))) "/app/example.cpp":14:3 1771
{xorv16qi3}
 (expr_list:REG_DEAD (reg/v:V16QI 106 [ bD.22792 ])
(nil)))
(insn 8 7 9 2 (set (reg:V16QI 108)
(const_vector:V16QI [
(const_int 0 [0]) repeated x16
]))
"/opt/compiler-explorer/arm64/gcc-trunk-20240816/aarch64-unknown-linux-gnu/lib/gcc/aarch64-unknown-linux-gnu/15.0.0/include/arm_neon.h":7311:10
1268 {*aarch64_simd_movv16qi}
 (nil))
(insn 9 8 10 2 (set (reg:V16QI 103 [ _6 ])
(unspec:V16QI [
(xor:V16QI (reg:V16QI 107 [ _1 ])
(reg:V16QI 108))
] UNSPEC_AESE))
"/opt/compiler-explorer/arm64/gcc-trunk-20240816/aarch64-unknown-linux-gnu/lib/gcc/aarch64-unknown-linux-gnu/15.0.0/include/arm_neon.h":7311:10
5203 {aarch64_crypto_aesev16qi}
 (expr_list:REG_EQUAL (unspec:V16QI [
(reg:V16QI 107 [ _1 ])
] UNSPEC_AESE)
(expr_list:REG_DEAD (reg:V16QI 108)
(expr_list:REG_DEAD (reg:V16QI 107 [ _1 ])
(nil)
```

Which is:
r107 = r105 ^ r106
r108 = 0 (used again below)
r103 = AESE (r107 ^ r108)

But there is no pattern to accept `AESE (r107)` which partly causes the issue
here.
Actually 3->2 should have done it but since i2 didn't change we reject it even
though it is cost is better.

```
Trying 8, 7 -> 9:
8: r108:V16QI=const_vector
7: r107:V16QI=r105:V16QI^r113:V16QI
  REG_DEAD r113:V16QI
9: r103:V16QI=unspec[r107:V16QI^r108:V16QI] 229
  REG_DEAD r107:V16QI
  REG_EQUAL unspec[r107:V16QI] 229
Failed to match this instruction:
(parallel [
(set (reg:V16QI 103 [ _6 ])
(unspec:V16QI [
(xor:V16QI (reg/v:V16QI 105 [ aD.22791 ])
(reg:V16QI 113))
] UNSPEC_AESE))
(set (reg:V16QI 108)
(const_vector:V16QI [
(const_int 0 [0]) repeated x16
]))
])
Failed to match this instruction:
(parallel [
(set (reg:V16QI 103 [ _6 ])
(unspec:V16QI [
(xor:V16QI (reg/v:V16QI 105 [ aD.22791 ])
(reg:V16QI 113))
] UNSPEC_AESE))
(set (reg:V16QI 108)
(const_vector:V16QI [
(const_int 0 [0]) repeated x16
]))
])
Successfully matched this instruction:
(set (reg:V16QI 108)
(const_vector:V16QI [
(const_int 0 [0]) repeated x16
]))
Successfully matched this instruction:
(set (reg:V16QI 103 [ _6 ])
(unspec:V16QI [
(xor:V16QI (reg/v:V16QI 105 [ aD.22791 ])
(reg:V16QI 113))
] UNSPEC_AESE))
allowing combination of insns 7, 8 and 9
original costs 8 + 4 + 4 = 16
replacement costs 4 + 4 = 8
i2 didn't change, not doing this
```

I would have expected that only for 2->2 combines and not 3->2 combines which
should almost always be a win .

[Bug rtl-optimization/116398] New: [15 Regression] gcc.target/aarch64/ashltidisi.c fails

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

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

Bug ID: 116398
   Summary: [15 Regression] gcc.target/aarch64/ashltidisi.c fails
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

FAIL: gcc.target/aarch64/ashltidisi.c scan-assembler-times asr 3

Extracted testcase:
```
__int128_t __attribute__((noinline)) shift_53_i(int data) {
return (__int128_t)data << 53;
}
```

14 produced:
```
mov w1, w0
lsl x0, x1, 53
sbfxx1, x1, 11, 21
ret
```

While 15 produces:
```
sxtwx1, w0
lsl x0, x1, 53
asr x1, x1, 11
ret
```

[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug modula2/116181] -Wlto-type-mismatch warnings/errors during m2 bootstrap

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

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

Gaius Mulley  changed:

   What|Removed |Added

  Attachment #58855|0   |1
is obsolete||
  Attachment #58928|0   |1
is obsolete||

--- Comment #5 from Gaius Mulley  ---
Created attachment 58942
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58942&action=edit
Proposed fix v8

Here is a reworked patch set for all but two -Wodr warnings in the m2 front
end.

[Bug modula2/116378] [15 Regression] M2 bootstrap fails on x86_64-darwin after r15-2876

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

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

Gaius Mulley  changed:

   What|Removed |Added

  Attachment #58934|0   |1
is obsolete||

--- Comment #12 from Gaius Mulley  ---
Created attachment 58943
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58943&action=edit
Proposed fix v8

Here is a proposed patch for PR 116181, I was wondering how this patch affects
darwin?  git master + this patch bootstraps on aarch64, ppc64le, amd64 GNU
Linux.
It resolves all -Wodr warnings (except two).  Posting it here as the initial
patch for PR 116181 caused this PR (apologies).

RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]

[Li, Pan2 via Gcc-bugs]

Never mind, looks still conflict, could you please help to double check about 
it?
Current upstream should be 3c9c93f3c923c4a0ccd42db4fd26a944a3c91458.

└─(09:18:27 on master ✭)──> git apply tmp.patch 

──(Sat,Aug17)─┘
error: patch failed: gcc/config/riscv/riscv.cc:11010
error: gcc/config/riscv/riscv.cc: patch does not apply

Pan

-Original Message-
From: Zhijin Zeng  
Sent: Friday, August 16, 2024 9:30 PM
To: Li, Pan2 
Cc: gcc-patc...@gcc.gnu.org; gcc-bugs@gcc.gnu.org; Kito Cheng 

Subject: Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
[PR116305]

Sorry, the line number changed. The newest version as follow,

This patch is to fix the bug (BugId:116305) introduced by the commit
bd93ef for risc-v target.

The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
if TARGET_MIN_VLEN is larger than 128 in riscv_convert_vector_bits. So
it changes the value of BYTES_PER_RISCV_VECTOR. For example, before
merging the commit bd93ef and if TARGET_MIN_VLEN is 256, the value
of BYTES_PER_RISCV_VECTOR should be [8, 8], but now [16, 16]. The value
of riscv_bytes_per_vector_chunk and BYTES_PER_RISCV_VECTOR are no longer
equal.

Prologue will use BYTES_PER_RISCV_VECTOR.coeffs[1] to estimate the vlenb
register value in riscv_legitimize_poly_move, and dwarf2cfi will also
get the estimated vlenb register value in riscv_dwarf_poly_indeterminate_value
to calculate the number of times to multiply the vlenb register value.

So need to change the factor from riscv_bytes_per_vector_chunk to
BYTES_PER_RISCV_VECTOR, otherwise we will get the incorrect dwarf
information. The incorrect example as follow:

```
csrr    t0,vlenb
slli    t1,t0,1
sub     sp,sp,t1

.cfi_escape 0xf,0xb,0x72,0,0x92,0xa2,0x38,0,0x34,0x1e,0x23,0x50,0x22
```

The sequence '0x92,0xa2,0x38,0' means the vlenb register, '0x34' means
the literal 4, '0x1e' means the multiply operation. But in fact, the
vlenb register value just need to multiply the literal 2.

gcc/ChangeLog:

        * config/riscv/riscv.cc (riscv_dwarf_poly_indeterminate_value):

gcc/testsuite/ChangeLog:

        * gcc.target/riscv/rvv/base/scalable_vector_cfi.c: New test.

Signed-off-by: Zhijin Zeng 
---
 gcc/config/riscv/riscv.cc                     |  4 +--
 .../riscv/rvv/base/scalable_vector_cfi.c      | 32 +++
 2 files changed, 34 insertions(+), 2 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 1f60d8f9711..8b7123e043e 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -11010,12 +11010,12 @@ static unsigned int
 riscv_dwarf_poly_indeterminate_value (unsigned int i, unsigned int *factor,
                                      int *offset)
 {
-  /* Polynomial invariant 1 == (VLENB / riscv_bytes_per_vector_chunk) - 1.
+  /* Polynomial invariant 1 == (VLENB / BYTES_PER_RISCV_VECTOR) - 1.
      1. TARGET_MIN_VLEN == 32, polynomial invariant 1 == (VLENB / 4) - 1.
      2. TARGET_MIN_VLEN > 32, polynomial invariant 1 == (VLENB / 8) - 1.
   */
   gcc_assert (i == 1);
-  *factor = riscv_bytes_per_vector_chunk;
+  *factor = BYTES_PER_RISCV_VECTOR.coeffs[1];
   *offset = 1;
   return RISCV_DWARF_VLENB;
 }
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
new file mode 100644
index 000..184da10caf3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-g -O3 -march=rv64gcv -mabi=lp64d" } */
+/* { dg-skip-if "" { *-*-* } {"-O2" "-O1" "-O0" "-Og" "-Oz" "-flto"} } */
+/* { dg-final { scan-assembler {cfi_escape .*0x92,0xa2,0x38,0,0x32,0x1e} } } */
+
+#include "riscv_vector.h"
+
+#define PI_2 1.570796326795
+
+extern void func(float *result);
+
+void test(const float *ys, const float *xs, float *result, size_t length) {
+    size_t gvl = __riscv_vsetvlmax_e32m2();
+    vfloat32m2_t vpi2 = __riscv_vfmv_v_f_f32m2(PI_2, gvl);
+
+    for(size_t i = 0; i < length;) {
+        gvl = __riscv_vsetvl_e32m2(length - i);
+        vfloat32m2_t y = __riscv_vle32_v_f32m2(ys, gvl);
+        vfloat32m2_t x = __riscv_vle32_v_f32m2(xs, gvl);
+        vbool16_t mask0  = __riscv_vmflt_vv_f32m2_b16(x, y, gvl);
+        vfloat32m2_t fixpi = __riscv_vfrsub_vf_f32m2_mu(mask0, vpi2, vpi2, 0, 
gvl);
+
+        __riscv_vse32_v_f32m2(result, fixpi, gvl);
+
+        func(result);
+
+        i += gvl;
+        ys += gvl;
+        xs += gvl;
+        result += gvl;
+    }
+}
--
2.34.1

> From: "Li, Pan2"
> Date:  Fri, Aug 16, 2024, 21:05
> Subject:  RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
> [PR116305]
> To: "Zhijin Zeng"
> Cc: "gcc-patc...@gcc.gnu.org", 
> "gcc-bugs@gcc

[Bug tree-optimization/116352] [15 regression] ICE when building opencv-4.9.0 (error: definition in block 208 does not dominate use in block 188) since r15-2820-gab18785840d7b8

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

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

Sam James  changed:

   What|Removed |Added

 CC||cmuellner at gcc dot gnu.org,
   ||ptomsich at gcc dot gnu.org,
   ||tsamismanolis at gmail dot com
Summary|[15 regression] ICE when|[15 regression] ICE when
   |building opencv-4.9.0   |building opencv-4.9.0
   |(error: definition in block |(error: definition in block
   |208 does not dominate use   |208 does not dominate use
   |in block 188)   |in block 188) since
   ||r15-2820-gab18785840d7b8

--- Comment #7 from Sam James  ---
r15-2820-gab18785840d7b8

Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]

[Zhijin Zeng]

The patch for 3c9c93 as follow. But it's a little strange that this patch 
hasn't changed and I don't know why it apply fail. May you directly modify the 
riscv.cc if this version still conflict? The riscv.cc just changed two lines. 
Thank you again.
Zhijjin

This patch is to fix the bug (BugId:116305) introduced by the commit
bd93ef for risc-v target.

The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
if TARGET_MIN_VLEN is larger than 128 in riscv_convert_vector_bits. So
it changes the value of BYTES_PER_RISCV_VECTOR. For example, before
merging the commit bd93ef and if TARGET_MIN_VLEN is 256, the value
of BYTES_PER_RISCV_VECTOR should be [8, 8], but now [16, 16]. The value
of riscv_bytes_per_vector_chunk and BYTES_PER_RISCV_VECTOR are no longer
equal.

Prologue will use BYTES_PER_RISCV_VECTOR.coeffs[1] to estimate the vlenb
register value in riscv_legitimize_poly_move, and dwarf2cfi will also
get the estimated vlenb register value in riscv_dwarf_poly_indeterminate_value
to calculate the number of times to multiply the vlenb register value.

So need to change the factor from riscv_bytes_per_vector_chunk to
BYTES_PER_RISCV_VECTOR, otherwise we will get the incorrect dwarf
information. The incorrect example as follow:

```
csrr    t0,vlenb
slli    t1,t0,1
sub     sp,sp,t1

.cfi_escape 0xf,0xb,0x72,0,0x92,0xa2,0x38,0,0x34,0x1e,0x23,0x50,0x22
```

The sequence '0x92,0xa2,0x38,0' means the vlenb register, '0x34' means
the literal 4, '0x1e' means the multiply operation. But in fact, the
vlenb register value just need to multiply the literal 2.

gcc/ChangeLog:

        * config/riscv/riscv.cc (riscv_dwarf_poly_indeterminate_value):

gcc/testsuite/ChangeLog:

        * gcc.target/riscv/rvv/base/scalable_vector_cfi.c: New test.

Signed-off-by: Zhijin Zeng 
---
 gcc/config/riscv/riscv.cc                     |  4 +--
 .../riscv/rvv/base/scalable_vector_cfi.c      | 32 +++
 2 files changed, 34 insertions(+), 2 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 1f60d8f9711..8b7123e043e 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -11010,12 +11010,12 @@ static unsigned int
 riscv_dwarf_poly_indeterminate_value (unsigned int i, unsigned int *factor,
                                      int *offset)
 {
-  /* Polynomial invariant 1 == (VLENB / riscv_bytes_per_vector_chunk) - 1.
+  /* Polynomial invariant 1 == (VLENB / BYTES_PER_RISCV_VECTOR) - 1.
      1. TARGET_MIN_VLEN == 32, polynomial invariant 1 == (VLENB / 4) - 1.
      2. TARGET_MIN_VLEN > 32, polynomial invariant 1 == (VLENB / 8) - 1.
   */
   gcc_assert (i == 1);
-  *factor = riscv_bytes_per_vector_chunk;
+  *factor = BYTES_PER_RISCV_VECTOR.coeffs[1];
   *offset = 1;
   return RISCV_DWARF_VLENB;
 }
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
new file mode 100644
index 000..184da10caf3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-g -O3 -march=rv64gcv -mabi=lp64d" } */
+/* { dg-skip-if "" { *-*-* } {"-O2" "-O1" "-O0" "-Og" "-Oz" "-flto"} } */
+/* { dg-final { scan-assembler {cfi_escape .*0x92,0xa2,0x38,0,0x32,0x1e} } } */
+
+#include "riscv_vector.h"
+
+#define PI_2 1.570796326795
+
+extern void func(float *result);
+
+void test(const float *ys, const float *xs, float *result, size_t length) {
+    size_t gvl = __riscv_vsetvlmax_e32m2();
+    vfloat32m2_t vpi2 = __riscv_vfmv_v_f_f32m2(PI_2, gvl);
+
+    for(size_t i = 0; i < length;) {
+        gvl = __riscv_vsetvl_e32m2(length - i);
+        vfloat32m2_t y = __riscv_vle32_v_f32m2(ys, gvl);
+        vfloat32m2_t x = __riscv_vle32_v_f32m2(xs, gvl);
+        vbool16_t mask0  = __riscv_vmflt_vv_f32m2_b16(x, y, gvl);
+        vfloat32m2_t fixpi = __riscv_vfrsub_vf_f32m2_mu(mask0, vpi2, vpi2, 0, 
gvl);
+
+        __riscv_vse32_v_f32m2(result, fixpi, gvl);
+
+        func(result);
+
+        i += gvl;
+        ys += gvl;
+        xs += gvl;
+        result += gvl;
+    }
+}
--
2.34.1


> From: "Li, Pan2"
> Date:  Sat, Aug 17, 2024, 09:20
> Subject:  RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
> [PR116305]
> To: "Zhijin Zeng"
> Cc: "gcc-patc...@gcc.gnu.org", 
> "gcc-bugs@gcc.gnu.org", "Kito 
> Cheng"
> Never mind, looks still conflict, could you please help to double check about 
> it?
> Current upstream should be 3c9c93f3c923c4a0ccd42db4fd26a944a3c91458.
> 
> └─(09:18:27 on master ✭)──> git apply tmp.patch                               
>                                                                               
>                                                                 
> ──(Sat,Aug17)─┘
> error: patch failed: gcc/config/riscv/riscv.cc:11010
> error: gcc/config/riscv/riscv.cc: patch does not apply
> 
> Pan
>

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #174 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #169)
> I'll try running gcc testsuite with the sh-elf cross compiler on old sh-sim.
> There may not be much chance, but it might catch the wrong code bug.

The results w/wo -mlra are exactly the same on the patched compiler. For
example,

make check-gcc RUNTESTFLAGS="execute.exp --target_board=sh-sim/-m4"
make check-gcc RUNTESTFLAGS="execute.exp --target_board=sh-sim/-m4/-mlra"

=== gcc Summary ===

# of expected passes23910
# of unexpected failures96

The result for the unpatched trunk compiler with -m4 is same,  but with  -m4
for  the vanilla compiler 14.0.1 20240222 shows 

# of unexpected failures93

and 3 new failures on the current master compilers are

> FAIL: gcc.c-torture/execute/struct-ret-1.c   -O2  execution test
> FAIL: gcc.c-torture/execute/struct-ret-1.c   -O3 -g  execution test
> FAIL: gcc.c-torture/execute/struct-ret-1.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  execution test

It doesn't look that this issue is the cause of the segfault.  This is a bad
sign, though.
Can the unpatched trunk gcc15 bootstrap with reverting enable -mlra by default
patch in c#121 in the first place?  I assume that gcc14 can bootstrap
successfully with -mno-lra.

I'll look the above execution errors into more closely.

BTW, the patched (58832, 58833,58883,58905) gcc 14.0.1 20240222 has no above 3
FAILs for gcc.c-torture/execute/struct-ret-1.c and moreover -mlra fixes one
more case

PASS: gcc.c-torture/execute/struct-ret-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

which was failed even with unpatched 14.0.1.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #175 from Kazumoto Kojima  ---
(In reply to John Paul Adrian Glaubitz from comment #172)
> ../../../src/libgcc/libgcc2.c:538:1: internal compiler error: Illegal
> instruction
> root@tirpitz:..sh4-linux-gnu/libgcc>
> 
> Could this be just an issue of the compiler generating invalid code?

I assume.  A wrong code can make a bad register value which will be used as an
instruction address.  If that address is in a data object, for example, it can
cause an illegal instruction error.

[Bug rtl-optimization/114522] [15 regression] gcc.target/arm/aes_xor_combine.c scan-assembler-not veor fails after r14-9692-g839bc42772ba7a

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Christophe Lyon from comment #2)
> The patch has been un-reverted, so indeed this failure has re-appeared.
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=9dbff9c05520a74e6cd337578f27b56c941f64f3
> 
> on aarch64, this triggers more regressions:
> 
> Running gcc:gcc.target/aarch64/aarch64.exp ...
> FAIL: gcc.target/aarch64/aes_xor_combine.c scan-assembler-not eor
> FAIL: gcc.target/aarch64/aes_xor_combine.c scan-assembler-not mov

This bug

> FAIL: gcc.target/aarch64/ashltidisi.c scan-assembler-times asr 3
Filed off as PR 116398 .



> FAIL: gcc.target/aarch64/bitfield-bitint-abi-align16.c check-function-bodies
> g1
> FAIL: gcc.target/aarch64/bitfield-bitint-abi-align16.c check-function-bodies
> g16
> FAIL: gcc.target/aarch64/bitfield-bitint-abi-align16.c check-function-bodies
> g16p
> FAIL: gcc.target/aarch64/bitfield-bitint-abi-align16.c check-function-bodies
> g1p
> FAIL: gcc.target/aarch64/bitfield-bitint-abi-align16.c check-function-bodies
> g8
> FAIL: gcc.target/aarch64/bitfield-bitint-abi-align16.c check-function-bodies
> g8p
> FAIL: gcc.target/aarch64/bitfield-bitint-abi-align8.c check-function-bodies
> g1
> FAIL: gcc.target/aarch64/bitfield-bitint-abi-align8.c check-function-bodies
> g16
> FAIL: gcc.target/aarch64/bitfield-bitint-abi-align8.c check-function-bodies
> g16p
> FAIL: gcc.target/aarch64/bitfield-bitint-abi-align8.c check-function-bodies
> g1p
> FAIL: gcc.target/aarch64/bitfield-bitint-abi-align8.c check-function-bodies
> g8
> FAIL: gcc.target/aarch64/bitfield-bitint-abi-align8.c check-function-bodies
> g8p

Didn't look into these but I am 99% sure it is the same issue as PR 116398 .

Didn't look to see which ones still fail.

RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]

[Li, Pan2 via Gcc-bugs]

Ok, I will commit it if no surprise from test as manually changing.

Pan

-Original Message-
From: Zhijin Zeng  
Sent: Saturday, August 17, 2024 10:46 AM
To: Li, Pan2 
Cc: gcc-patc...@gcc.gnu.org; gcc-bugs@gcc.gnu.org; Kito Cheng 

Subject: Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
[PR116305]

The patch for 3c9c93 as follow. But it's a little strange that this patch 
hasn't changed and I don't know why it apply fail. May you directly modify the 
riscv.cc if this version still conflict? The riscv.cc just changed two lines. 
Thank you again.
Zhijjin

This patch is to fix the bug (BugId:116305) introduced by the commit
bd93ef for risc-v target.

The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
if TARGET_MIN_VLEN is larger than 128 in riscv_convert_vector_bits. So
it changes the value of BYTES_PER_RISCV_VECTOR. For example, before
merging the commit bd93ef and if TARGET_MIN_VLEN is 256, the value
of BYTES_PER_RISCV_VECTOR should be [8, 8], but now [16, 16]. The value
of riscv_bytes_per_vector_chunk and BYTES_PER_RISCV_VECTOR are no longer
equal.

Prologue will use BYTES_PER_RISCV_VECTOR.coeffs[1] to estimate the vlenb
register value in riscv_legitimize_poly_move, and dwarf2cfi will also
get the estimated vlenb register value in riscv_dwarf_poly_indeterminate_value
to calculate the number of times to multiply the vlenb register value.

So need to change the factor from riscv_bytes_per_vector_chunk to
BYTES_PER_RISCV_VECTOR, otherwise we will get the incorrect dwarf
information. The incorrect example as follow:

```
csrr    t0,vlenb
slli    t1,t0,1
sub     sp,sp,t1

.cfi_escape 0xf,0xb,0x72,0,0x92,0xa2,0x38,0,0x34,0x1e,0x23,0x50,0x22
```

The sequence '0x92,0xa2,0x38,0' means the vlenb register, '0x34' means
the literal 4, '0x1e' means the multiply operation. But in fact, the
vlenb register value just need to multiply the literal 2.

gcc/ChangeLog:

        * config/riscv/riscv.cc (riscv_dwarf_poly_indeterminate_value):

gcc/testsuite/ChangeLog:

        * gcc.target/riscv/rvv/base/scalable_vector_cfi.c: New test.

Signed-off-by: Zhijin Zeng 
---
 gcc/config/riscv/riscv.cc                     |  4 +--
 .../riscv/rvv/base/scalable_vector_cfi.c      | 32 +++
 2 files changed, 34 insertions(+), 2 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 1f60d8f9711..8b7123e043e 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -11010,12 +11010,12 @@ static unsigned int
 riscv_dwarf_poly_indeterminate_value (unsigned int i, unsigned int *factor,
                                      int *offset)
 {
-  /* Polynomial invariant 1 == (VLENB / riscv_bytes_per_vector_chunk) - 1.
+  /* Polynomial invariant 1 == (VLENB / BYTES_PER_RISCV_VECTOR) - 1.
      1. TARGET_MIN_VLEN == 32, polynomial invariant 1 == (VLENB / 4) - 1.
      2. TARGET_MIN_VLEN > 32, polynomial invariant 1 == (VLENB / 8) - 1.
   */
   gcc_assert (i == 1);
-  *factor = riscv_bytes_per_vector_chunk;
+  *factor = BYTES_PER_RISCV_VECTOR.coeffs[1];
   *offset = 1;
   return RISCV_DWARF_VLENB;
 }
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
new file mode 100644
index 000..184da10caf3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-g -O3 -march=rv64gcv -mabi=lp64d" } */
+/* { dg-skip-if "" { *-*-* } {"-O2" "-O1" "-O0" "-Og" "-Oz" "-flto"} } */
+/* { dg-final { scan-assembler {cfi_escape .*0x92,0xa2,0x38,0,0x32,0x1e} } } */
+
+#include "riscv_vector.h"
+
+#define PI_2 1.570796326795
+
+extern void func(float *result);
+
+void test(const float *ys, const float *xs, float *result, size_t length) {
+    size_t gvl = __riscv_vsetvlmax_e32m2();
+    vfloat32m2_t vpi2 = __riscv_vfmv_v_f_f32m2(PI_2, gvl);
+
+    for(size_t i = 0; i < length;) {
+        gvl = __riscv_vsetvl_e32m2(length - i);
+        vfloat32m2_t y = __riscv_vle32_v_f32m2(ys, gvl);
+        vfloat32m2_t x = __riscv_vle32_v_f32m2(xs, gvl);
+        vbool16_t mask0  = __riscv_vmflt_vv_f32m2_b16(x, y, gvl);
+        vfloat32m2_t fixpi = __riscv_vfrsub_vf_f32m2_mu(mask0, vpi2, vpi2, 0, 
gvl);
+
+        __riscv_vse32_v_f32m2(result, fixpi, gvl);
+
+        func(result);
+
+        i += gvl;
+        ys += gvl;
+        xs += gvl;
+        result += gvl;
+    }
+}
--
2.34.1


> From: "Li, Pan2"
> Date:  Sat, Aug 17, 2024, 09:20
> Subject:  RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
> [PR116305]
> To: "Zhijin Zeng"
> Cc: "gcc-patc...@gcc.gnu.org", 
> "gcc-bugs@gcc.gnu.org", "Kito 
> Cheng"
> Never mind, looks still conflict, could you please help to double check about 
> it?
> Current upstream should be 3c9c93f3c923c4a0ccd42db4fd26a944a3c91458.
> 
> └─(09:18:27 on master ✭)──> git apply tm

[Bug target/116305] RISC-V: dwarf cfi_escape information is incorrect when use vlenb to get scalable frame

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Pan Li :

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

commit r15-2962-ga11dcaff9fc94971188d54310d3053e9f68a0d3d
Author: æ¾æ²»é 
Date:   Wed Aug 14 14:06:23 2024 +0800

RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]

This patch is to fix the bug (BugId:116305) introduced by the commit
bd93ef for risc-v target.

The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
if TARGET_MIN_VLEN is larger than 128 in riscv_convert_vector_bits. So
it changes the value of BYTES_PER_RISCV_VECTOR. For example, before
merging the commit bd93ef and if TARGET_MIN_VLEN is 256, the value
of BYTES_PER_RISCV_VECTOR should be [8, 8], but now [16, 16]. The value
of riscv_bytes_per_vector_chunk and BYTES_PER_RISCV_VECTOR are no longer
equal.

Prologue will use BYTES_PER_RISCV_VECTOR.coeffs[1] to estimate the vlenb
register value in riscv_legitimize_poly_move, and dwarf2cfi will also
get the estimated vlenb register value in
riscv_dwarf_poly_indeterminate_value
to calculate the number of times to multiply the vlenb register value.

So need to change the factor from riscv_bytes_per_vector_chunk to
BYTES_PER_RISCV_VECTOR, otherwise we will get the incorrect dwarf
information. The incorrect example as follow:

```
csrr    t0,vlenb
slli    t1,t0,1
sub     sp,sp,t1

.cfi_escape 0xf,0xb,0x72,0,0x92,0xa2,0x38,0,0x34,0x1e,0x23,0x50,0x22
```

The sequence '0x92,0xa2,0x38,0' means the vlenb register, '0x34' means
the literal 4, '0x1e' means the multiply operation. But in fact, the
vlenb register value just need to multiply the literal 2.

PR target/116305

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_dwarf_poly_indeterminate_value):
Take
BYTES_PER_RISCV_VECTOR for *factor instead of
riscv_bytes_per_vector_chunk.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/scalable_vector_cfi.c: New test.

Signed-off-by: Zhijin Zeng 

RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]

[Li, Pan2 via Gcc-bugs]

Should be in upstream already.

Pan

-Original Message-
From: Li, Pan2  
Sent: Saturday, August 17, 2024 11:45 AM
To: Zhijin Zeng 
Cc: gcc-patc...@gcc.gnu.org; gcc-bugs@gcc.gnu.org; Kito Cheng 

Subject: RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
[PR116305]

Ok, I will commit it if no surprise from test as manually changing.

Pan

-Original Message-
From: Zhijin Zeng  
Sent: Saturday, August 17, 2024 10:46 AM
To: Li, Pan2 
Cc: gcc-patc...@gcc.gnu.org; gcc-bugs@gcc.gnu.org; Kito Cheng 

Subject: Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
[PR116305]

The patch for 3c9c93 as follow. But it's a little strange that this patch 
hasn't changed and I don't know why it apply fail. May you directly modify the 
riscv.cc if this version still conflict? The riscv.cc just changed two lines. 
Thank you again.
Zhijjin

This patch is to fix the bug (BugId:116305) introduced by the commit
bd93ef for risc-v target.

The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
if TARGET_MIN_VLEN is larger than 128 in riscv_convert_vector_bits. So
it changes the value of BYTES_PER_RISCV_VECTOR. For example, before
merging the commit bd93ef and if TARGET_MIN_VLEN is 256, the value
of BYTES_PER_RISCV_VECTOR should be [8, 8], but now [16, 16]. The value
of riscv_bytes_per_vector_chunk and BYTES_PER_RISCV_VECTOR are no longer
equal.

Prologue will use BYTES_PER_RISCV_VECTOR.coeffs[1] to estimate the vlenb
register value in riscv_legitimize_poly_move, and dwarf2cfi will also
get the estimated vlenb register value in riscv_dwarf_poly_indeterminate_value
to calculate the number of times to multiply the vlenb register value.

So need to change the factor from riscv_bytes_per_vector_chunk to
BYTES_PER_RISCV_VECTOR, otherwise we will get the incorrect dwarf
information. The incorrect example as follow:

```
csrr    t0,vlenb
slli    t1,t0,1
sub     sp,sp,t1

.cfi_escape 0xf,0xb,0x72,0,0x92,0xa2,0x38,0,0x34,0x1e,0x23,0x50,0x22
```

The sequence '0x92,0xa2,0x38,0' means the vlenb register, '0x34' means
the literal 4, '0x1e' means the multiply operation. But in fact, the
vlenb register value just need to multiply the literal 2.

gcc/ChangeLog:

        * config/riscv/riscv.cc (riscv_dwarf_poly_indeterminate_value):

gcc/testsuite/ChangeLog:

        * gcc.target/riscv/rvv/base/scalable_vector_cfi.c: New test.

Signed-off-by: Zhijin Zeng 
---
 gcc/config/riscv/riscv.cc                     |  4 +--
 .../riscv/rvv/base/scalable_vector_cfi.c      | 32 +++
 2 files changed, 34 insertions(+), 2 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 1f60d8f9711..8b7123e043e 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -11010,12 +11010,12 @@ static unsigned int
 riscv_dwarf_poly_indeterminate_value (unsigned int i, unsigned int *factor,
                                      int *offset)
 {
-  /* Polynomial invariant 1 == (VLENB / riscv_bytes_per_vector_chunk) - 1.
+  /* Polynomial invariant 1 == (VLENB / BYTES_PER_RISCV_VECTOR) - 1.
      1. TARGET_MIN_VLEN == 32, polynomial invariant 1 == (VLENB / 4) - 1.
      2. TARGET_MIN_VLEN > 32, polynomial invariant 1 == (VLENB / 8) - 1.
   */
   gcc_assert (i == 1);
-  *factor = riscv_bytes_per_vector_chunk;
+  *factor = BYTES_PER_RISCV_VECTOR.coeffs[1];
   *offset = 1;
   return RISCV_DWARF_VLENB;
 }
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
new file mode 100644
index 000..184da10caf3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-g -O3 -march=rv64gcv -mabi=lp64d" } */
+/* { dg-skip-if "" { *-*-* } {"-O2" "-O1" "-O0" "-Og" "-Oz" "-flto"} } */
+/* { dg-final { scan-assembler {cfi_escape .*0x92,0xa2,0x38,0,0x32,0x1e} } } */
+
+#include "riscv_vector.h"
+
+#define PI_2 1.570796326795
+
+extern void func(float *result);
+
+void test(const float *ys, const float *xs, float *result, size_t length) {
+    size_t gvl = __riscv_vsetvlmax_e32m2();
+    vfloat32m2_t vpi2 = __riscv_vfmv_v_f_f32m2(PI_2, gvl);
+
+    for(size_t i = 0; i < length;) {
+        gvl = __riscv_vsetvl_e32m2(length - i);
+        vfloat32m2_t y = __riscv_vle32_v_f32m2(ys, gvl);
+        vfloat32m2_t x = __riscv_vle32_v_f32m2(xs, gvl);
+        vbool16_t mask0  = __riscv_vmflt_vv_f32m2_b16(x, y, gvl);
+        vfloat32m2_t fixpi = __riscv_vfrsub_vf_f32m2_mu(mask0, vpi2, vpi2, 0, 
gvl);
+
+        __riscv_vse32_v_f32m2(result, fixpi, gvl);
+
+        func(result);
+
+        i += gvl;
+        ys += gvl;
+        xs += gvl;
+        result += gvl;
+    }
+}
--
2.34.1


> From: "Li, Pan2"
> Date:  Sat, Aug 17, 2024, 09:20
> Subject:  RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
> [PR116305]
> To: "Zh

[Bug target/116305] RISC-V: dwarf cfi_escape information is incorrect when use vlenb to get scalable frame

[zhijin.zeng at spacemit dot com via Gcc-bugs]

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

曾治金  changed:

   What|Removed |Added

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

--- Comment #2 from 曾治金  ---
Fix it in gcc repo a11dcaff9fc94971188d54310d3053e9f68a0d3d

Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]

[Zhijin Zeng]

This is my first time submitting a patch to gcc and sincerely thank you all for 
your help.
Zhijin

> From: "Li, Pan2"
> Date:  Sat, Aug 17, 2024, 12:15
> Subject:  RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
> [PR116305]
> To: "Li, Pan2", "Zhijin Zeng"
> Cc: "gcc-patc...@gcc.gnu.org", 
> "gcc-bugs@gcc.gnu.org", "Kito 
> Cheng"
> Should be in upstream already.
> 
> Pan
> 
> -Original Message-
> From: Li, Pan2  
> Sent: Saturday, August 17, 2024 11:45 AM
> To: Zhijin Zeng 
> Cc: gcc-patc...@gcc.gnu.org; gcc-bugs@gcc.gnu.org; Kito Cheng 
> 
> Subject: RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
> [PR116305]
> 
> Ok, I will commit it if no surprise from test as manually changing.
> 
> Pan
> 
> -Original Message-
> From: Zhijin Zeng  
> Sent: Saturday, August 17, 2024 10:46 AM
> To: Li, Pan2 
> Cc: gcc-patc...@gcc.gnu.org; gcc-bugs@gcc.gnu.org; Kito Cheng 
> 
> Subject: Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value 
> [PR116305]
> 
> The patch for 3c9c93 as follow. But it's a little strange that this patch 
> hasn't changed and I don't know why it apply fail. May you directly modify 
> the riscv.cc if this version still conflict? The riscv.cc just changed two 
> lines. Thank you again.
> Zhijjin
> 
> This patch is to fix the bug (BugId:116305) introduced by the commit
> bd93ef for risc-v target.
> 
> The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
> if TARGET_MIN_VLEN is larger than 128 in riscv_convert_vector_bits. So
> it changes the value of BYTES_PER_RISCV_VECTOR. For example, before
> merging the commit bd93ef and if TARGET_MIN_VLEN is 256, the value
> of BYTES_PER_RISCV_VECTOR should be [8, 8], but now [16, 16]. The value
> of riscv_bytes_per_vector_chunk and BYTES_PER_RISCV_VECTOR are no longer
> equal.
> 
> Prologue will use BYTES_PER_RISCV_VECTOR.coeffs[1] to estimate the vlenb
> register value in riscv_legitimize_poly_move, and dwarf2cfi will also
> get the estimated vlenb register value in riscv_dwarf_poly_indeterminate_value
> to calculate the number of times to multiply the vlenb register value.
> 
> So need to change the factor from riscv_bytes_per_vector_chunk to
> BYTES_PER_RISCV_VECTOR, otherwise we will get the incorrect dwarf
> information. The incorrect example as follow:
> 
> ```
> csrr    t0,vlenb
> slli    t1,t0,1
> sub     sp,sp,t1
> 
> .cfi_escape 0xf,0xb,0x72,0,0x92,0xa2,0x38,0,0x34,0x1e,0x23,0x50,0x22
> ```
> 
> The sequence '0x92,0xa2,0x38,0' means the vlenb register, '0x34' means
> the literal 4, '0x1e' means the multiply operation. But in fact, the
> vlenb register value just need to multiply the literal 2.
> 
> gcc/ChangeLog:
> 
>         * config/riscv/riscv.cc (riscv_dwarf_poly_indeterminate_value):
> 
> gcc/testsuite/ChangeLog:
> 
>         * gcc.target/riscv/rvv/base/scalable_vector_cfi.c: New test.
> 
> Signed-off-by: Zhijin Zeng 
> ---
>  gcc/config/riscv/riscv.cc                     |  4 +--
>  .../riscv/rvv/base/scalable_vector_cfi.c      | 32 +++
>  2 files changed, 34 insertions(+), 2 deletions(-)
>  create mode 100644 
> gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
> 
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 1f60d8f9711..8b7123e043e 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -11010,12 +11010,12 @@ static unsigned int
>  riscv_dwarf_poly_indeterminate_value (unsigned int i, unsigned int *factor,
>                                       int *offset)
>  {
> -  /* Polynomial invariant 1 == (VLENB / riscv_bytes_per_vector_chunk) - 1.
> +  /* Polynomial invariant 1 == (VLENB / BYTES_PER_RISCV_VECTOR) - 1.
>       1. TARGET_MIN_VLEN == 32, polynomial invariant 1 == (VLENB / 4) - 1.
>       2. TARGET_MIN_VLEN > 32, polynomial invariant 1 == (VLENB / 8) - 1.
>    */
>    gcc_assert (i == 1);
> -  *factor = riscv_bytes_per_vector_chunk;
> +  *factor = BYTES_PER_RISCV_VECTOR.coeffs[1];
>    *offset = 1;
>    return RISCV_DWARF_VLENB;
>  }
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
> new file mode 100644
> index 000..184da10caf3
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/scalable_vector_cfi.c
> @@ -0,0 +1,32 @@
> +/* { dg-do compile } */
> +/* { dg-options "-g -O3 -march=rv64gcv -mabi=lp64d" } */
> +/* { dg-skip-if "" { *-*-* } {"-O2" "-O1" "-O0" "-Og" "-Oz" "-flto"} } */
> +/* { dg-final { scan-assembler {cfi_escape .*0x92,0xa2,0x38,0,0x32,0x1e} } } 
> */
> +
> +#include "riscv_vector.h"
> +
> +#define PI_2 1.570796326795
> +
> +extern void func(float *result);
> +
> +void test(const float *ys, const float *xs, float *result, size_t length) {
> +    size_t gvl = __riscv_vsetvlmax_e32m2();
> +    vfloat32m2_t vpi2 = __riscv_vfmv_v_f_f32m2(PI_2, gvl);
> +
> +    for(size_t i = 0; i < length;) {
> +        gvl = __riscv_vsetvl_e32m2(length - i);
> +    

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #176 from John Paul Adrian Glaubitz  ---
I am trying a full bootstrap with the patches applied now but with LRA disabled
by default.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #177 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #175)
> (In reply to John Paul Adrian Glaubitz from comment #172)
> > ../../../src/libgcc/libgcc2.c:538:1: internal compiler error: Illegal
> > instruction
> > root@tirpitz:..sh4-linux-gnu/libgcc>
> > 
> > Could this be just an issue of the compiler generating invalid code?
> 
> I assume.  A wrong code can make a bad register value which will be used as
> an instruction address.  If that address is in a data object, for example,
> it can cause an illegal instruction error.

It could also be a latent bug exposed, like ..

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

(just two I could of think right now, perhaps there more of course)

As for bootstrapping, afaik Jeff Law has been bootstrapping vanilla sh4
compiler on a regular basis, see also
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660457.html

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #178 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #177)
> As for bootstrapping, afaik Jeff Law has been bootstrapping vanilla sh4
> compiler on a regular basis, see also
> https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660457.html

I assume he is doing cross-compiled bootstraps which is why he is never running
the miscompiled code, is he?

Also, did he try with LRA enabled?

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #179 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #178)
> (In reply to Oleg Endo from comment #177)
> > As for bootstrapping, afaik Jeff Law has been bootstrapping vanilla sh4
> > compiler on a regular basis, see also
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660457.html
> 
> I assume he is doing cross-compiled bootstraps which is why he is never
> running the miscompiled code, is he?

I don't know.  He's not ever disclosed the details of his test setup for all
the various targets...


> 
> Also, did he try with LRA enabled?

No, LRA is not enabled in the vanilla version as of yet.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #180 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #174)
> > FAIL: gcc.c-torture/execute/struct-ret-1.c   -O2  execution test
> > FAIL: gcc.c-torture/execute/struct-ret-1.c   -O3 -g  execution test
> > FAIL: gcc.c-torture/execute/struct-ret-1.c   -O2 -flto 
> > -fno-use-linker-plugin -flto-partition=none  execution test
...
> I'll look the above execution errors into more closely.

It turned out that these FAILs don't show the real compiler issue but rather a
problem with my newlib build.  Sorry for the noise.

[Bug rtl-optimization/116390] [ext_dce][avr][15 regression]Another ICE for avrtiny and optimization

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Known to work||14.1.0
Summary|Another ICE for avrtiny and |[ext_dce][avr][15
   |optimization|regression]Another ICE for
   ||avrtiny and optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-08-17
  Component|target  |rtl-optimization
 Ever confirmed|0   |1
 CC||law at gcc dot gnu.org

--- Comment #1 from Georg-Johann Lay  ---
This seems to be a bug in ext_dce, and it can be worked around with
-fno-ext-dce.

>From .expand, there is this insn:

(insn 27 26 0 (set (reg/v:SI 60 [ n2 ])
(zero_extend:SI (reg/v:HI 63 [ n1 ]))) "pr116390-i.cpp":33:20 -1
 (nil))

which .ext_dce turns into a paradoxical subreg:

Processing insn:
   27: r60:SI=zero_extend(r63:HI)
  REG_DEAD r63:HI
Trying to simplify pattern:
(zero_extend:SI (reg/v:HI 63 [ n1 ]))
rescanning insn with uid = 27.
Successfully transformed to:
(subreg:SI (reg/v:HI 63 [ n1 ]) 0)

This paradoxical subreg it there until register allocation, which turns the
insn into

(insn 27 145 28 5 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
(const_int 7 [0x7])) [4 %sfp+7 S4 A8])
(reg:SI 26 r26)) "pr116390-i.cpp":33:20 119 {*movsi_split}
 (nil))

and this is complete rubbish because R26:SI overlaps with the frame pointer
R28:HI.

Apart from that, representing a zero_extend as a paradoxical subreg is spoiling
all respective combine patterns that combine shifts with zero_extends.  Are we
supposed to rewrite all of them using paradoxical subregs?