[Bug other/113399] [14 Regression] -ffold-mem-offsets should not be a target option

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug testsuite/113452] [14 regression] 32-bit gcc.target/i386/sse4_1-stv-1.c FAILs

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug testsuite/113446] [14 Regression] gcc.dg/tree-ssa/scev-16.c FAILs

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug testsuite/113446] [14 Regression] gcc.dg/tree-ssa/scev-16.c FAILs

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

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

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

https://gcc.gnu.org/g:484f48f03cf9a382b3bcf4dadac09c4ee59c2ddf

commit r14-8210-g484f48f03cf9a382b3bcf4dadac09c4ee59c2ddf
Author: Jakub Jelinek 
Date:   Thu Jan 18 08:51:53 2024 +0100

testsuite: Fix up scev-16.c test [PR113446]

This test FAILs on i686-linux or e.g. sparc*-solaris*, because
it uses vect_int effective target outside of */vect/ testsuite.
That is wrong, vect_int assumes the extra added flags by vect.exp
by default, which aren't added in other testsuites.

The following patch fixes that by moving the test into gcc.dg/vect/
and doing small tweaks.

2024-01-18  Jakub Jelinek  

PR tree-optimization/112774
PR testsuite/113446
* gcc.dg/tree-ssa/scev-16.c: Move test ...
* gcc.dg/vect/pr112774.c: ... here.  Add PR comment line, use
dg-additional-options instead of dg-options and drop
-fdump-tree-vect-details.

[Bug tree-optimization/112774] Vectorize the loop by inferring nonwrapping information from arrays

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

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

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

https://gcc.gnu.org/g:484f48f03cf9a382b3bcf4dadac09c4ee59c2ddf

commit r14-8210-g484f48f03cf9a382b3bcf4dadac09c4ee59c2ddf
Author: Jakub Jelinek 
Date:   Thu Jan 18 08:51:53 2024 +0100

testsuite: Fix up scev-16.c test [PR113446]

This test FAILs on i686-linux or e.g. sparc*-solaris*, because
it uses vect_int effective target outside of */vect/ testsuite.
That is wrong, vect_int assumes the extra added flags by vect.exp
by default, which aren't added in other testsuites.

The following patch fixes that by moving the test into gcc.dg/vect/
and doing small tweaks.

2024-01-18  Jakub Jelinek  

PR tree-optimization/112774
PR testsuite/113446
* gcc.dg/tree-ssa/scev-16.c: Move test ...
* gcc.dg/vect/pr112774.c: ... here.  Add PR comment line, use
dg-additional-options instead of dg-options and drop
-fdump-tree-vect-details.

[Bug c++/113457] Trying to emulate views::concat with std::generator gives ICE on co_yield: "internal compiler error: in canonicalize_component_ref, at gimplify.cc"

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

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

--- Comment #7 from Andrew Pinski  ---
Created attachment 57134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57134=edit
Reduced as far as I can make it right now

Here is more reduced testcase though I see it depends on
__remove_reference/__remove_cv/__is_array though.

[Bug testsuite/113452] [14 regression] 32-bit gcc.target/i386/sse4_1-stv-1.c FAILs

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

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

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

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

commit r14-8209-gb032f4b7da56a225a0a14d40da2d47a6fcbab3f3
Author: Jakub Jelinek 
Date:   Thu Jan 18 08:46:15 2024 +0100

testsuite: Fix up gcc.target/i386/sse4_1-stv-1.c test [PR113452]

From what I can see, this test has been written for a backend fix and
assumes the loop isn't vectorized (at least, it wasn't when the test was
added, it contains an early exit), but that is no longer true and because
of the vectorization it now contains an instruction which the test scans
for not being present.

I think we should just disable vectorization here.

2024-01-18  Jakub Jelinek  

PR testsuite/113452
* gcc.target/i386/sse4_1-stv-1.c: Add -fno-tree-vectorize to
dg-options.

[Bug other/113399] [14 Regression] -ffold-mem-offsets should not be a target option

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

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

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

https://gcc.gnu.org/g:1203fc2e6a40c65896763554f62cacfb4bd6a836

commit r14-8208-g1203fc2e6a40c65896763554f62cacfb4bd6a836
Author: Jakub Jelinek 
Date:   Thu Jan 18 08:45:09 2024 +0100

opts: Fix up -ffold-mem-offsets option keywords

While the option was originally meant to be a Target option for a single
target, it is an option for all targets, so should be Common rather than
Target, and because it is an optimization option which could be different
in between different LTO TUs, I've added Optimization keyword too.
From what I can see, Bool is a non-documented non-existing keyword (at
least, grep Bool *.awk shows nothing, so I've dropped that too.  Seems
that the option parsing simply parses and ignores any non-existing
keywords.

Guess we should drop the Bool keywords from the gcc/config/riscv/riscv.opt
file eventually, so that people don't copy this around.

2024-01-18  Jakub Jelinek  

PR other/113399
* common.opt (ffold-mem-offsets): Remove Target and Bool keywords,
add
Common and Optimization.

[Bug libstdc++/113470] New: Should std::tuple_size be a complete type?

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 113470
   Summary: Should std::tuple_size be a complete type?
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

The following code snippet is currently showing implementation divergence
(https://godbolt.org/z/P8oWqf5sT). MSVC STL's std::tuple_size is a
complete type, while libstdc++'s and libc++'s are not.
```
#include 

// constexpr auto foo = sizeof(std::tuple_size);// Correctly rejected.
constexpr auto bar = sizeof(std::tuple_size); // Should be
well-formed?
```

It seems that MSVC STL's behavior is justified by
https://eel.is/c++draft/contents#1 and https://eel.is/c++draft/tuple.syn, given
that only the primary templates of std::tuple_size and std::tuple_element are
marked `// not defined`.

I'm not sure whether this should be considered as a bug. Perhaps an LWG issue
is wanted.

[Bug tree-optimization/113431] [14 Regression] Wrong code at -O3

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #16 from Richard Biener  ---
Fixed.

[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
Fixed.

[Bug tree-optimization/113431] [14 Regression] Wrong code at -O3

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

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

--- Comment #15 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-8207-gb981d5c60b8ef78e2adecd6b5d7e36f9e5e61c54
Author: Richard Biener 
Date:   Wed Jan 17 14:05:42 2024 +0100

tree-optimization/113431 - wrong dependence with invariant load

The vectorizer dependence analysis is confused with invariant loads
when figuring whether the circumstances are so that we preserve
scalar stmt execution order.  The following rectifies this.

PR tree-optimization/113431
* tree-vect-data-refs.cc (vect_preserves_scalar_order_p):
When there is an invariant load we might not preserve
scalar order.

* gcc.dg/vect/pr113431.c: New testcase.

[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:0f3880d6ad0e40c4a8b6d94b2c93931cdf42

commit r14-8206-g0f3880d6ad0e40c4a8b6d94b2c93931cdf42
Author: Richard Biener 
Date:   Wed Jan 17 13:24:22 2024 +0100

tree-optimization/113374 - early break vect and virtual operands

The following fixes wrong virtual operands being used for peeled
early breaks where we can have different live ones and for multiple
exits it makes sure to update the correct PHI arguments.

I've introduced SET_PHI_ARG_DEF_ON_EDGE so we can avoid using
a wrong edge to compute the PHI arg index from.

I've took the liberty to understand the code again and refactor
and comment it a bit differently.  The main functional change
is that we preserve the live virtual operand on all exits.

PR tree-optimization/113374
* tree-ssa-operands.h (SET_PHI_ARG_DEF_ON_EDGE): New.
* tree-vect-loop.cc (move_early_exit_stmts): Update
virtual LC PHIs.
* tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg):
Refactor.  Preserve virtual LC PHIs on all exits.

* gcc.dg/vect/vect-early-break_106-pr113374.c: New testcase.

[Bug c/113469] New: RISC-V: Illegal Insn for test case 920501-8.c when make linux for rv32

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

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

Bug ID: 113469
   Summary: RISC-V: Illegal Insn for test case 920501-8.c when
make linux for rv32
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pan2.li at intel dot com
  Target Milestone: ---

The test case will have illegal instruction when `make linux` build of the repo
riscv-gnu-toolchain for rv32.

1. Build.
../__RISC-V_INSTALL___RV32/bin/riscv32-unknown-linux-gnu-gcc
gcc/testsuite/gcc.c-torture/execute/920501-8.c -march=rv32gcv -mabi=ilp32d
-mtune=rocket -mcmodel=medlow -fdiagnostics-plain-output -O2 -w -lm -o
./920501-8.elf -static

2. Run with qemu
../build-qemu/qemu-riscv32 -cpu rv32,vlen=512,v=true,vext_spec=v1.0
920501-8.elf
Illegal instruction (core dumped)

3. When enter function __printf_buffer (comes from libc.a), it will go to insn
like below for the first insn
  __printf_buffer:
auipc a5,0x5f  => directly jump to the vmv insn and then illegal insn met.
...
vmv.v.i.v1,0

4. After some investigation, the function __printf_buffer should be the
   function Xprintf_buffer in glibc/stdio-common/vfprintf-internal.c. You can
   use the below command to compile it.

   cd glibc/stdio-common/
../../__RISC-V_INSTALL___RV32/bin/riscv32-unknown-linux-gnu-gcc
vfprintf-internal.c  \
 -c -std=gnu11 -fgnu89-inline  -mcmodel=medlow -O2 -Wall -Wwrite-strings
-Wundef \
 -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common
-Wstrict-prototypes -Wold-style-definition  \
 -fmath-errno -fPIE   -ftls-model=initial-exec -I../include \

-I/home/pli/gcc/444/riscv-gnu-toolchain/build-glibc-linux-rv32gcv-ilp32d/stdio-common
 \
 -I/home/pli/gcc/444/riscv-gnu-toolchain/build-glibc-linux-rv32gcv-ilp32d 
-I../sysdeps/unix/sysv/linux/riscv/rv32 \
 -I../sysdeps/unix/sysv/linux/riscv  -I../sysdeps/riscv/nptl 
-I../sysdeps/unix/sysv/linux/generic/wordsize-32   \
 -I../sysdeps/unix/sysv/linux/generic  -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux  \
 -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu 
-I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  \
 -I../sysdeps/unix  -I../sysdeps/posix  \
 -I../sysdeps/riscv/rv32/rvd  -I../sysdeps/riscv/rv32/rvf  
-I../sysdeps/riscv/rvf \
 -I../sysdeps/riscv/rvd  -I../sysdeps/riscv/rv32  -I../sysdeps/riscv  \
 -I../sysdeps/ieee754/ldbl-128  -I../sysdeps/ieee754/dbl-64 
-I../sysdeps/ieee754/flt-32  \
 -I../sysdeps/wordsize-32   -I../sysdeps/ieee754  -I../sysdeps/generic \
 -I.. -I../libio -I. -nostdinc -isystem
/home/pli/gcc/444/riscv-gnu-toolchain/__RISC-V_INSTALL___RV32/lib/gcc/riscv32-unknown-linux-gnu/14.0.1/include
\
 -isystem
/home/pli/gcc/444/riscv-gnu-toolchain/__RISC-V_INSTALL___RV32/lib/gcc/riscv32-unknown-linux-gnu/14.0.1/include-fixed
  \
 -isystem /home/pli/gcc/444/riscv-gnu-toolchain/linux-headers/include \
 -D_LIBC_REENTRANT -include
/home/pli/gcc/444/riscv-gnu-toolchain/build-glibc-linux-rv32gcv-ilp32d/libc-modules.h
\
 -DMODULE_NAME=libc -include ../include/libc-symbols.h  -DPIC  \
 -DTOP_NAMESPACE=glibc -D_IO_MTSAFE_IO -o test.o

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #6 from Sam James  ---
Created attachment 57133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57133=edit
mpi-add.o (correct)

Attaching a good version of mpi-add.o too for comparison (built with
r14-6644-g5060825aa78b3d).

[Bug target/113312] Add __attribute__((no_callee_saved_registers)) for Intel FRED

[xin at zytor dot com via Gcc-bugs]

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

Xin Li  changed:

   What|Removed |Added

 CC||xin at zytor dot com

--- Comment #22 from Xin Li  ---
Per Peter's suggestion, I added __attribute__((no_callee_saved_registers)) to a
linux source tree containing FRED patches:
https://github.com/xinli-intel/linux-fred-public/commit/12c38143a5c33e89f2b3d8906629dd4f23f8d79c.
 And I compiled the linux code with a gcc built from
https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/pr113312/gcc-13.

Following are my observations:
1) the generated kernel boots fine on both FRED Simics model and bare metal.
2) the asm code generated for fred_entry_from_{user,kernel}() are the same,
i.e., __attribute__((no_callee_saved_registers)) makes no difference (Peter
said the FRED dispatch points simply do not have significant register pressure
– intentionally).
3) other functions with __attribute__((no_callee_saved_registers)) do get rid
of pushing/popping clobbered registers, and cause no issues because they are
top-level functions, only invoked by tail call, meaning the following case
won't happen:

:
...
mov (%rbx), %r13
call foo
mov %rax, (%r13)
...

otherwise foo() is NOT a top-level function.

[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

[newbie-02 at gmx dot de via Gcc-bugs]

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

--- Comment #4 from newbie-02  ---
(In reply to Joseph S. Myers from comment #3)  

:-)  - thank you, you are my hero,  

> If you're doing arithmetic with constant operands, it might be
> folded at compile time; make sure you're using -frounding-math to avoid that.

Think that was it, using volatile variables makes a difference.  
( I hate! cheating compilers and I hate me again and again seeking for that
same trap ... sorry )   

reg. 'availability': think that 'modul' / each 'modul' which provides the
datatype should also provide the rounding mode ... good logic? Effort to
implement is once, users seeking would be over and over again ... endless ...
not good.

[Bug testsuite/111850] [14 regression] gcc.target/powerpc/fold-vec-extract-char.p7.c fails after r14-4664-g04c9cf5c786b94

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #6 from Kewen Lin  ---
Should be fixed on trunk.

[Bug c/47409] volatile struct member bug

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gnu at kosak dot com

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

[Bug target/113468] copy of large struct violates semantics of 'volatile'

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 47409.

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

[Bug testsuite/111850] [14 regression] gcc.target/powerpc/fold-vec-extract-char.p7.c fails after r14-4664-g04c9cf5c786b94

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

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

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

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

commit r14-8201-gf4156fbf7d6d641f8aade8028e87cf302350c3c0
Author: Kewen Lin 
Date:   Thu Jan 18 00:00:52 2024 -0600

testsuite, rs6000: Adjust fold-vec-extract-char.p7.c [PR111850]

As PR101169 comment #c4 shows, previsouly the addi count
update on fold-vec-extract-char.p7.c covered a sub-optimal
code gen issue.  On trunk, pass fold-mem-offsets helps to
recover the best code sequence, so this patch is to
revert the count back to the original which matches the
optimal addi count.

PR testsuite/111850

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/fold-vec-extract-char.p7.c: Update the
checking count of addi to 6.

[Bug target/113468] New: copy of large struct violates semantics of 'volatile'

[gnu at kosak dot com via Gcc-bugs]

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

Bug ID: 113468
   Summary: copy of large struct violates semantics of 'volatile'
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnu at kosak dot com
  Target Milestone: ---

Created attachment 57132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57132=edit
the .ii file from --save-temps

Hello,

I'm not 100% certain, but I'm pretty sure that the assembly generated for this
code violates the semantics for 'volatile'. The reason I think so is that it
reads and writes the same memory locations more than once, and also reads and
writes them out of order. I believe that both of these actions violate the
rules for 'volatile'.

```
struct Foo {
volatile int values[256];
};

void copy(const Foo *src, Foo *dest) {
*dest = *src;
}

```

Relevant assembly on x86_64, invoked with g++ -S -O3 test.cc

```
_Z4copyPK3FooPS_:
.LFB0:
.cfi_startproc
endbr64
movq(%rdi), %rdx
movq%rdi, %rax
movq%rsi, %rcx
movq%rdx, (%rsi)
movq1016(%rdi), %rdx
leaq8(%rsi), %rdi
andq$-8, %rdi
subq%rdi, %rcx
movq%rdx, 1016(%rsi)
subq%rcx, %rax
addl$1024, %ecx
movq%rax, %rsi
shrl$3, %ecx
rep movsq
ret
.cfi_endproc
```

Analysis:

The compiler wants to use "rep movsq", but Foo is only aligned to 4 bytes, so
the generated code takes extra pains to make sure that the destination register
rdi is aligned to an 8 byte boundary so that "rep movsq" can be efficient.

The trick used is to first move the first and last quadwords (regardless of
alignment), and then do a "rep movsq" of the interior, but with care taken so
that the destination is aligned to an 8-byte boundary. There is a 2x2 matrix of
cases here: src will be aligned to either 4 or 8; likewise dest will be aligned
to 4 or 8. To illustrate the problem, consider when src and dest are aligned to
4 but not 8. For the sake of the example, assume that src is 0x5004 and
dest is 0x6004

First, the code moves a quadword from [0x5004] to [0x6004]. Call this
[FIRST STEP] because we reference it below.

Then it moves a quadword from [0x5004+1016] to [0x6004+1016]. To my
mind this already is a problem because it violates the ordering assumptions of
'volatile'. But that's not the only problem.

Finally the code does a bit of arithmetic and masking, ultimately ending up
with rsi = 0x5008 and rdi = 0x6008 and then it does the "rep movsq".

My main objection is that this is a partially overlapping re-read (and
re-write) of one-half of the same quadword that was copied in [FIRST STEP],
which I believe violates the rules for volatile. If Foo were a bank of hardware
registers this might be an unwelcome access pattern.

Similar violations happen for the other cases in the 2x2 matrix.

Apologies if I'm wrong about the above. I'm certainly not a 'volatile' expert
but this strikes me as rather hinky.

I would stress that I have no objection to the code for the non-volatile case.

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

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #5 from Sam James  ---
I also see test failures for mpfr and gmp. I was hoping something else would
turn up without wrapped integers so I could reduce it a bit easier :)

[Bug c++/54483] undefined reference to static constexpr in .so

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #13 from Thiago Macieira  ---
(In reply to Andrew Pinski from comment #11)
> You still need:
> constexpr float A::val;

In C++11 mode, yes.

C++17 made all static constexpr data members implicitly inline, which change
the situation. Inline variables ought to be emitted on use and merged at
runtime.

This explanation does not change the resolution of this bug report. But if you
can update your code to use -std=c++17, gnu++17 or later, then the problem goes
away.

[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

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

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

--- Comment #16 from Kewen Lin  ---
(In reply to Michael Matz from comment #15)
> Umm.  I just noticed this one as we now try to implement userspace live
> patching
> for ppc64le.  The point of the "before" NOPs is (and always was) that they
> are
> completely out of the way of patchable but as-of-yet unpatched functions.
> 
> For ppc that means the "before" and "after" NOPs cannot be consecutive.  The
> two
> NOP sets being consecutive was never a design criteria or requirement.
> 
> So, while the original bug is fixed by what was committed (local entry was
> skipping the patching-nops), the chosen solution is exactly the wrong one :-/

Thanks for the input! Sigh, sorry that we picked up the wrong one :(, you may
have noticed that the main consideration to choose the current one is to keep
it align with the consecutive NOPs described by the documentation, we need a
separate command line option as Segher's review comment in
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600239.html. Now we have
PR112980 filed for the requested behavior, let's discuss how to support it
there.

[Bug target/53929] [meta-bug] -masm=intel with global symbol

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #24 from LIU Hao  ---
I've composed a proposal to address this issue:

 
https://github.com/lhmouse/mcfgthread/wiki/Formalized-Intel-Syntax-for-x86#the-proposal


The proposal is to treat names between `ptr` and `[` as symbols, and to treat
to treat names between `[` and `]` as registers. This

   lea  rax, bx[rip]

should be rejected due to invalidity, while

   lea  rax, BYTE PTR bx[rip]

can be parsed as referencing the symbol `bx` with no ambiguity.

[Bug target/113465] [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #5 from Thiago Macieira  ---
> I don't think that's the same. That situation over there is C++11, where the
> constexpr variable is *not* static.

I meant not *inline*.

[Bug target/113465] [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #4 from Thiago Macieira  ---
(In reply to Andrew Pinski from comment #3)
> See PR 54483 .
> 
> *** This bug has been marked as a duplicate of bug 54483 ***

I don't think that's the same. That situation over there is C++11, where the
constexpr variable is *not* static.

I forgot to say that in my case it is inline because it's C++17.

On use, GCC emits a copy of the variable:
struct __declspec(dllimport) QLocale
{
static constexpr inline int FirstTwoDigitYear = 1900;
};

template void f(const T &);
void f() { f(QLocale::FirstTwoDigitYear); }

results in:

_Z1fv:
movq__imp__ZN7QLocale17FirstTwoDigitYearE(%rip), %rcx
jmp _Z1fIiEvRKT_
_ZN7QLocale17FirstTwoDigitYearE:
.long   1900

This copy is useless. The equivalent code for ELF and Mach-O ABIs is fine
because the relocation would find it, if the original variable doesn't exist in
the .so. But on Windows, that __imp_ prefix implies it's an import from another
DLL, which *must* have emitted its copy and exported it.

Clang and MSVC also do the import, but don't emit that copy. See
https://mingw.godbolt.org/z/aKsaYKThT.

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #4 from Sam James  ---
Created attachment 57131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57131=edit
somewhat reduced t-mpi-point.c (not standalone)

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #3 from Sam James  ---
```
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240114/work/gcc-14-20240114/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
14.0.1_pre20240114 p16' --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --enable-cet
--disable-systemtap --enable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --with-isl --disable-isl-version-check
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --with-build-config='bootstrap-O3 bootstrap-lto
bootstrap-cet'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240114 (experimental) (Gentoo Hardened 14.0.1_pre20240114
p16)
```

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #2 from Sam James  ---
Created attachment 57130
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57130=edit
mpi-add.i

gcc -m32 -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -O3 -march=znver2 -ggdb3
-fvisibility=hidden -fno-delete-null-pointer-checks -Wall -MT mpi-add.lo -MD
-MP -MF .deps/mpi-add.Tpo -c mpi-add.c  -fPIC -DPIC -o .libs/mpi-add.o
-save-temps

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #1 from Sam James  ---
Created attachment 57129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57129=edit
mpi-add.o (miscompiled)

The bad object is mpi-add.o, specifically _gcry_mpi_add_ui in there (verified
with optimize pragmas).

[Bug tree-optimization/113467] New: [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

Bug ID: 113467
   Summary: [14 regression] libgcrypt-1.10.3 is miscompiled
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

With -O3 -march=znver2 -m32, libgcrypt-1.10.3 is miscompiled on amd64:

```
t-mpi-point: context_alloc: tv[0].'NIST P-521': sample point multiply failed:
  k:
7FE0003F0007F7801FFC00FFF030001F03E8F3E8003803E803EA003F0467F3E803E800FFE3E8
 Qx:
7CAACB2174E1A97A63BABF4E9E6E82389898A1607E4737672B1070E5F66535E406455BFD70F2EBEEEF3F2DB9303E8DB3941190575849708A456188899714C96E74
expected Qx:
00C1002DC2884EEDADB3F9B468BBEBD55980799852C506D37271FFCD006919DB3A96DF8FE91EF6ED4B9081B1809E8F2C2B28AF5FCBF524147C73CB0B913D6FAB0995
 Qy:
00990438D2386F13AC4FC5BE2F8690FC5BC1B3F5A312FD113D0DF71AD01C755A89C393087575588707247E45C22931BA45B1B9B02BE8049CD2B487CF68666DDD38D2
expected Qy:
01614E8A62C8293DD2AA6EF27D30974A4FD185019FA8EF4F982DA48698CECF706581F69EE9ED67A9C231EC9D0934D0F674646153273BCBB345E923B1EC1386A1A4AD
t-mpi-point: context_alloc: tv[1].'NIST P-521': sample point multiply failed:
  k:
03FFF7FFE007FFE3FC01FFE0001FE0200000010100C0010080F040F80100C1
 Qx:
00A416B8B436A53456DBB98262BF27B80E80F9F0CA440CE867A80E56B486686837ECC41F557D4098D348EADCB8C9F05AE072EE631CE6979BA63269B698500C8F8002
expected Qx:
0172CD22CBE0634B6BFEE24BB1D350F384A945ED618ECAD48AADC6C1BC0DCC107F0FFE9FE14DC929F90153F390C25BE5D3A73A56F9ACCB0C72C768753869732D0DC4
 Qy:
44D7D325D0CDEB1714AB1EE6BD62A166A2953E9799B706B49917402ACE58FF06CE207022D212958F596B0D94511FD5EC61185B6FF46B9ECBBFFBC6B1806CFCA674
expected Qy:
00D249CFB570DA4CC48FB5426A928B43D7922F787373B6182408FBC71706E7527E8414C79167F3C999FF58DE352D238F1FE7168C658D338F72696F2F889A97DE23C5
FAIL: t-mpi-point
```

Bisect said the first bad commit was one of:
r14-7195-g411de96dbf2bda
r14-7194-g6cb155a6cf3142
r14-7196-g99c0a540d6689e

I can reproduce with:
```
wget https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.3.tar.bz2
tar xvf libgcrypt-1.10.3.tar.bz2 && cd libgcrypt-1.10.3
./configure --host=i686-pc-linux-gnu --disable-doc CFLAGS="-O3 -march=znver2"
CC="gcc -m32"
make -j$(nproc)
make -j$(nproc) check
```

The 't-mpi-point' test will fail.

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org
   Last reconfirmed||2024-01-18
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=99888
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Kewen Lin  ---
[1] made me realize that I forgot to post some comments here. (I thought I did
but actually didn't).

As Segher's review comments in [2], to support "before NOPs" before global
entry and "after NOPs" after global entry, we need to introduce a separate
command line option, I think it can be a target specific option, which is
enabled by default and we should mention its default behavior and impact in the
current documentation for -fpatchable-function-entry. I don't have a good name
candidate, any suggestions?

Considering that the current behavior aligning with consecutive NOPs looks
useless (this request and [1]), an alternative is to aggressively change the
current behavior to "before NOPs" before global entry and "after NOPs" after
global entry.

Any preference or other ideas?  Any comments are highly appreciated.

I think with either (any) proposal it's inevitable to make the current behavior
of -fpatchable-function-entry on "before NOPs" change, we should also document
this change in releases/changes.html.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888#c15
[2] https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600239.html

[Bug tree-optimization/113458] Missed SLP for reduction of multiplication/addition with promotion

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

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

--- Comment #2 from Hongtao Liu  ---

> But if we reduce n to 4, the loop based vectorizer is not able to handle it
> either.

Do we support 1 element vector(i.e V1SI) in vectorizer?
and it also relies on backend support of dot_prodv4qi.

[Bug target/113465] [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
See PR 54483 .

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

[Bug c++/54483] undefined reference to static constexpr in .so

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||thiago at kde dot org

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

[Bug target/113465] [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

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

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

--- Comment #2 from Andrew Pinski  ---
Plus I think the C++ standard says the definition is still required ...

[Bug target/113465] [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ABI

--- Comment #1 from Andrew Pinski  ---
IIRC this is what the IA64 ABI says to do.

clang might be getting it wrong ...

[Bug rtl-optimization/113464] ICE: in lower_asm, at gimple-lower-bitint.cc:5200 with invalid __asm__ on _BitInt() at -O1 and above

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 57128
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57128=edit
testcase triggering SIGSEGV at -O0

Slightly different testcase, triggers SIGSEGV at -O0 at a similar place:
$ x86_64-pc-linux-gnu-gcc testcase2.c -wrapper valgrind,-q
==8413== Invalid read of size 8
==8413==at 0x271971F: var_to_partition (tree-ssa-live.h:163)
==8413==by 0x271971F: lower_asm (gimple-lower-bitint.cc:5199)
==8413==by 0x271971F: (anonymous
namespace)::bitint_large_huge::lower_stmt(gimple*)
(gimple-lower-bitint.cc:5236)
==8413==by 0x271BB69: gimple_lower_bitint() (gimple-lower-bitint.cc:6534)
==8413==by 0x13CBE7A: execute_one_pass(opt_pass*) (passes.cc:2646)
==8413==by 0x13CC76F: execute_pass_list_1(opt_pass*) (passes.cc:2755)
==8413==by 0x13CC7A8: execute_pass_list(function*, opt_pass*)
(passes.cc:2766)
==8413==by 0xFCC675: expand (cgraphunit.cc:1842)
==8413==by 0xFCC675: cgraph_node::expand() (cgraphunit.cc:1795)
==8413==by 0xFCD589: output_in_order (cgraphunit.cc:2192)
==8413==by 0xFCD589: symbol_table::compile() [clone .part.0]
(cgraphunit.cc:2396)
==8413==by 0xFD0537: compile (cgraphunit.cc:2312)
==8413==by 0xFD0537: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2584)
==8413==by 0x150E111: compile_file() (toplev.cc:474)
==8413==by 0xDE6E6B: do_compile (toplev.cc:2152)
==8413==by 0xDE6E6B: toplev::main(int, char**) (toplev.cc:2308)
==8413==by 0xDE864A: main (main.cc:39)
==8413==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==8413== 
during GIMPLE pass: bitintlower0
testcase2.c: In function 'bar':
testcase2.c:2:1: internal compiler error: Segmentation fault
2 | bar(void)
  | ^~~
0x150dc2f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:317
0x271971f var_to_partition(_var_map*, tree_node*)
/repo/gcc-trunk/gcc/tree-ssa-live.h:163
0x271971f lower_asm
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5199
0x271971f lower_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5236
0x271bb69 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6534
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/113466] New: ICE: verify_flow_info failed: returns_twice call is not first in basic block 7 with a __returns_twice__ function with _BitInt() argument

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113466
   Summary: ICE: verify_flow_info failed: returns_twice call is
not first in basic block 7 with a __returns_twice__
function with _BitInt() argument
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57127
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57127=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c
testcase.c: In function 'foo':
testcase.c:4:1: error: returns_twice call is not first in basic block 7
4 | foo(int x)
  | ^~~
bar (_8);
during GIMPLE pass: bitintlower0
testcase.c:4:1: internal compiler error: verify_flow_info failed
0xf8edde verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.cc:287
0x156029c checking_verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.h:214
0x156029c cleanup_tree_cfg_noloop
/repo/gcc-trunk/gcc/tree-cfgcleanup.cc:1154
0x156029c cleanup_tree_cfg(unsigned int)
/repo/gcc-trunk/gcc/tree-cfgcleanup.cc:1205
0x13c8a3c execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2057
0x13c8eee execute_todo
/repo/gcc-trunk/gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc testcase.c
testcase.c: In function 'foo':
testcase.c:4:1: error: returns_twice call is not first in basic block 7
4 | foo(int x)
  | ^~~
bar (_8);
during GIMPLE pass: bitintlower0
testcase.c:4:1: internal compiler error: verify_flow_info failed
0xf8edde verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.cc:287
0x156029c checking_verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.h:214
0x156029c cleanup_tree_cfg_noloop
/repo/gcc-trunk/gcc/tree-cfgcleanup.cc:1154
0x156029c cleanup_tree_cfg(unsigned int)
/repo/gcc-trunk/gcc/tree-cfgcleanup.cc:1205
0x13c8a3c execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2057
0x13c8eee execute_todo
/repo/gcc-trunk/gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/113465] New: [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

[thiago at kde dot org via Gcc-bugs]

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

Bug ID: 113465
   Summary: [mingw-w64] dllexported constexpr (inline) variables
not automatically emitted
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

Related to explicit instantiation of templates bugs:
Bug 89088, Bug 109380
though I'd argue that since that has a special syntax, it's different.

Testcase:
struct __declspec(dllexport) QLocale
{
static constexpr int FirstTwoDigitYear = 1900;
};

With GCC, this produces:
.file   "example.cpp"
.text
.ident  "GCC: (MinGW-W64 x86_64-ucrt-mcf-seh, built by Brecht Sanders)
13.1.0"

That is, nothing.

With Clang, that emits (simplified):
.text
.section   
.rdata$_ZN7QLocale17FirstTwoDigitYearE,"dr",discard,_ZN7QLocale17FirstTwoDigitYearE
.globl  _ZN7QLocale17FirstTwoDigitYearE #
@_ZN7QLocale17FirstTwoDigitYearE
.p2align2, 0x0
_ZN7QLocale17FirstTwoDigitYearE:
.long   1900# 0x76c

.section.drectve,"yni"
.ascii  " -export:_ZN7QLocale17FirstTwoDigitYearE,data"
.addrsig

MSVC also emits the variable, though how it causes the export to happen isn't
clear.

https://mingw.godbolt.org/z/ErbfdPaf8

This can be worked around by explicitly declaring the variable as if it were
not inline (before C++17):

constexpr int QLocale::FirstTwoDigitYear;

However, since this isn't required in any other platform and other compilers on
Windows don't require it either, developers are going to forget it. And very
likely, this issue is going to show up only when users compile their code,
depending on varying levels of optimisation and inlining.

[Bug c++/113457] Trying to emulate views::concat with std::generator gives ICE on co_yield: "internal compiler error: in canonicalize_component_ref, at gimplify.cc"

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

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

--- Comment #6 from Andrew Pinski  ---
So you can reproduce it easier without even vector or array:
```
#include 
using namespace std;
template 
[[nodiscard]] auto
concat(Ranges&&... ranges) -> generator
{
(co_yield ranges::elements_of(ranges), ...);
}
auto
main() -> int
{
int const numbers1[] = {4, 8, 15, 16, 23, 42};
double const numbers2[] = {4, 8, 15, 16, 23, 42};
return *concat(numbers1, numbers2).begin();
}

```

[Bug rtl-optimization/113464] New: ICE: in lower_asm, at gimple-lower-bitint.cc:5200 with invalid __asm__ on _BitInt() at -O1 and above

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113464
   Summary: ICE: in lower_asm, at gimple-lower-bitint.cc:5200 with
invalid __asm__ on _BitInt() at -O1 and above
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57126
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57126=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c 
during GIMPLE pass: bitintlower
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: in lower_asm, at
gimple-lower-bitint.cc:5200
4 | foo(void)
  | ^~~
0xd8ab5d lower_asm
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5200
0xd8ab5d lower_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5236
0x271bb69 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6534
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8193-20240117105849-g3340878009a-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8193-20240117105849-g3340878009a-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240117 (experimental) (GCC)

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

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

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

Li Pan  changed:

   What|Removed |Added

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

--- Comment #3 from Li Pan  ---
Fixed.

[Bug target/109615] Redundant VSETVL after optimized code of RVV

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

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

Li Pan  changed:

   What|Removed |Added

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

--- Comment #2 from Li Pan  ---
Fixed.

[Bug tree-optimization/113463] New: ICE: in extended_tree, at tree.h:6449 with _BitInt() used as offset

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113463
   Summary: ICE: in extended_tree, at tree.h:6449 with _BitInt()
used as offset
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57125
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57125=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c 
during GIMPLE pass: lower
testcase.c: In function 'foo':
testcase.c:4:11: internal compiler error: in extended_tree, at tree.h:6449
4 |  void foo (void)
  |   ^~~
0x784f0c wi::extended_tree<128>::extended_tree(tree_node const*)
/repo/gcc-trunk/gcc/tree.h:6449
0x784f0c wi::extended_tree<128>::extended_tree(tree_node const*)
/repo/gcc-trunk/gcc/tree.h:6446
0x784f0c generic_wide_int >::generic_wide_int(tree_node const* const&)
/repo/gcc-trunk/gcc/wide-int.h:847
0x784f0c wi::to_offset(tree_node const*)
/repo/gcc-trunk/gcc/tree.h:6401
0x784f0c extend_offset_range
/repo/gcc-trunk/gcc/gimple-ssa-warn-restrict.cc:402
0x118edfe set_base_and_offset
/repo/gcc-trunk/gcc/gimple-ssa-warn-restrict.cc:493
0x118f6ee builtin_memref
/repo/gcc-trunk/gcc/gimple-ssa-warn-restrict.cc:269
0x118fdbc check_bounds_or_overlap(pointer_query&, gimple*, tree_node*,
tree_node*, tree_node*, tree_node*, bool, bool)
/repo/gcc-trunk/gcc/gimple-ssa-warn-restrict.cc:2022
0x11929dc check_bounds_or_overlap(gimple*, tree_node*, tree_node*, tree_node*,
tree_node*, bool, bool)
/repo/gcc-trunk/gcc/gimple-ssa-warn-restrict.cc:2009
0x11684a2 gimple_fold_builtin_memory_op
/repo/gcc-trunk/gcc/gimple-fold.cc:992
0x116a363 gimple_fold_builtin
/repo/gcc-trunk/gcc/gimple-fold.cc:5093
0x116a363 gimple_fold_call
/repo/gcc-trunk/gcc/gimple-fold.cc:5664
0x116be2b fold_stmt_1
/repo/gcc-trunk/gcc/gimple-fold.cc:6431
0x2700b2f lower_stmt
/repo/gcc-trunk/gcc/gimple-low.cc:797
0x270184a lower_sequence
/repo/gcc-trunk/gcc/gimple-low.cc:229
0x270184a lower_gimple_bind
/repo/gcc-trunk/gcc/gimple-low.cc:886
0x27019e8 lower_function_body
/repo/gcc-trunk/gcc/gimple-low.cc:119
0x27019e8 execute
/repo/gcc-trunk/gcc/gimple-low.cc:206
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8193-20240117105849-g3340878009a-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8193-20240117105849-g3340878009a-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240117 (experimental) (GCC)

[Bug tree-optimization/113462] New: ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt() in a struct

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113462
   Summary: ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at
-O with _BitInt() in a struct
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57124
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57124=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c 
during GIMPLE pass: bitintlower
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: in handle_cast, at
gimple-lower-bitint.cc:1539
2 | foo(void)
  | ^~~
0xd88dea handle_cast
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:1539
0x27092c0 handle_operand
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:815
0x27141fd lower_mergeable_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2481
0x271914d lower_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5339
0x271bb69 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6534
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8193-20240117105849-g3340878009a-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8193-20240117105849-g3340878009a-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240117 (experimental) (GCC)

[Bug middle-end/110847] [13/14 Regression] Inaccurate GCC documentation about -Wtsan and -Wxor-used-as-pow warnings

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from sandra at gcc dot gnu.org ---
Fixed.

[Bug middle-end/110847] [13/14 Regression] Inaccurate GCC documentation about -Wtsan and -Wxor-used-as-pow warnings

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Sandra Loosemore :

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

commit r14-8200-g9a5e8f9d112adb0fdd0931f72a023cd77c09dd8c
Author: Sandra Loosemore 
Date:   Thu Jan 18 02:29:30 2024 +

Document negative forms of -Wtsan and -Wxor-used-as-pow [PR110847]

These warnings are enabled by default, thus the manual should document the
-no form instead of the positive form.

gcc/ChangeLog
PR middle-end/110847
* doc/invoke.texi (Option Summary): Document negative forms of
-Wtsan and -Wxor-used-as-pow.
(Warning Options): Likewise.

[Bug c++/113457] Trying to emulate views::concat with std::generator gives ICE on co_yield: "internal compiler error: in canonicalize_component_ref, at gimplify.cc"

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

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

--- Comment #5 from Andrew Pinski  ---
Reducing ...

[Bug target/113429] RISC-V: SPEC2017 527 cam4 miscompilation in autovec VLA build

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

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

--- Comment #10 from JuzheZhong  ---
I have commit V3 patch with rebasing since V2 patch conflicts with the trunk.

I think you can use trunk GCC validate CAM4 directly now.

[Bug target/113429] RISC-V: SPEC2017 527 cam4 miscompilation in autovec VLA build

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

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

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

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

commit r14-8199-ge935c0662fe6301d524c54bb5bd75e923abb61e9
Author: Juzhe-Zhong 
Date:   Thu Jan 18 09:08:15 2024 +0800

RISC-V: Add has compatible check for conflict vsetvl fusion

V3: Rebase to trunk and commit it.

This patch fixes SPEC2017 cam4 mismatch issue due to we miss has compatible
check
for conflict vsetvl fusion.

Buggy assembler before this patch:

.L69:
vsetvli a5,s1,e8,mf4,ta,ma  -> buggy vsetvl
vsetivlizero,8,e8,mf2,ta,ma
vmv.v.i v1,0
vse8.v  v1,0(a5)
j   .L37
.L68:
vsetvli a5,s1,e8,mf4,ta,ma  -> buggy vsetvl
vsetivlizero,8,e8,mf2,ta,ma
addia3,a5,8
vmv.v.i v1,0
vse8.v  v1,0(a5)
vse8.v  v1,0(a3)
addia4,a4,-16
li  a3,8
bltua4,a3,.L37
j   .L69
.L67:
vsetivlizero,8,e8,mf2,ta,ma
vmv.v.i v1,0
vse8.v  v1,0(a5)
addia5,sp,56
vse8.v  v1,0(a5)
addis4,sp,64
addia3,sp,72
vse8.v  v1,0(s4)
vse8.v  v1,0(a3)
addia4,a4,-32
li  a3,16
bltua4,a3,.L36
j   .L68

After this patch:

.L63:
ble s1,zero,.L49
sllia4,s1,3
li  a3,32
addia5,sp,48
bltua4,a3,.L62
vsetivlizero,8,e8,mf2,ta,ma
vmv.v.i v1,0
vse8.v  v1,0(a5)
addia5,sp,56
vse8.v  v1,0(a5)
addis4,sp,64
addia3,sp,72
vse8.v  v1,0(s4)
addia4,a4,-32
addia5,sp,80
vse8.v  v1,0(a3)
.L35:
li  a3,16
bltua4,a3,.L36
addia3,a5,8
vmv.v.i v1,0
addia4,a4,-16
vse8.v  v1,0(a5)
addia5,a5,16
vse8.v  v1,0(a3)
.L36:
li  a3,8
bltua4,a3,.L37
vmv.v.i v1,0
vse8.v  v1,0(a5)

Tested on both RV32/RV64 no regression, Ok for trunk ?

PR target/113429

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc
(pre_vsetvl::earliest_fuse_vsetvl_info): Fix bug.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/vlmax_conflict-4.c: Adapt test.
* gcc.target/riscv/rvv/vsetvl/vlmax_conflict-5.c: Ditto.

[Bug rtl-optimization/112401] RISC-V: So many redundant move instructions due to subreg handling on vector mode

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

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

--- Comment #3 from JuzheZhong  ---
vfloat32m4_t matrix_4x4_transpose_vslide(vfloat32m4_t src) {
vfloat32m1_t inMat0 = __riscv_vget_v_f32m4_f32m1(src, 0);
vfloat32m1_t inMat1 = __riscv_vget_v_f32m4_f32m1(src, 1);
vfloat32m1_t inMat2 = __riscv_vget_v_f32m4_f32m1(src, 2);
vfloat32m1_t inMat3 = __riscv_vget_v_f32m4_f32m1(src, 3);
vuint32m1_t oddMask_u32 = __riscv_vmv_v_x_u32m1(0x, 1);
vuint32m1_t evenMask_u32 = __riscv_vmv_v_x_u32m1(0x, 1);

vbool32_t oddMask = __riscv_vreinterpret_v_u32m1_b32(oddMask_u32);
// vl=4 in the following
// should be mapped to vslideup.vi
vfloat32m1_t transMat0 = __riscv_vslideup_vx_f32m1_tumu(oddMask,
inMat0,
inMat1,
1, 4);
vfloat32m1_t transMat2 = __riscv_vslideup_vx_f32m1_tumu(oddMask,
inMat2,
inMat3,
 1, 4);

vbool32_t evenMask = __riscv_vreinterpret_v_u32m1_b32(evenMask_u32);
// should be mapped to vslidedown.vi
vfloat32m1_t transMat1 = __riscv_vslidedown_vx_f32m1_tumu(evenMask,
  inMat1,
  inMat0,
  1, 4);
vfloat32m1_t transMat3 = __riscv_vslidedown_vx_f32m1_tumu(evenMask,
  inMat3,
  inMat2,
  1, 4);

// should be mapped to vslideup.vi
vfloat32m1_t outMat0 = __riscv_vslideup_vx_f32m1_tu(transMat0,
transMat2,
2, 4);
vfloat32m1_t outMat1 = __riscv_vslideup_vx_f32m1_tu(transMat1,
transMat3,
2, 4);

// vl=2 in the following
// should be mapped to vslidedown.vi
vfloat32m1_t outMat2 = __riscv_vslidedown_vx_f32m1_tu(transMat2,
  transMat0,
  2, 2);
vfloat32m1_t outMat3 = __riscv_vslidedown_vx_f32m1_tu(transMat3,
  transMat1,
  2, 2);

return __riscv_vcreate_v_f32m1_f32m4(outMat0,
 outMat1,
 outMat2,
 outMat3);




}


matrix_4x4_transpose_vslide:
li  a4,45056
addiw   a4,a4,-1366
vsetivlizero,1,e32,m1,ta,ma
li  a5,20480
vmv.v.x v0,a4
vsetivlizero,4,e32,m1,tu,mu
vl4re32.v   v4,0(a1)
addiw   a5,a5,1365
vmv1r.v v12,v4
vmv1r.v v3,v6
vslideup.vi v12,v5,1,v0.t
vslideup.vi v3,v7,1,v0.t
vsetivlizero,1,e32,m1,ta,ma
vmv1r.v v1,v12
vmv.v.x v0,a5
vsetivlizero,4,e32,m1,tu,mu
vslideup.vi v1,v3,2
vmv1r.v v2,v5
vmv1r.v v8,v1
vslidedown.vi   v2,v4,1,v0.t
vmv1r.v v1,v7
vmv1r.v v4,v2
vslidedown.vi   v1,v6,1,v0.t
vslideup.vi v4,v1,2
vsetivlizero,2,e32,m1,tu,ma
vmv1r.v v9,v4
vslidedown.vi   v3,v12,2
vslidedown.vi   v1,v2,2
vmv1r.v v10,v3
vmv1r.v v11,v1
vs4r.v  v8,0(a0)
ret

[Bug rtl-optimization/112401] RISC-V: So many redundant move instructions due to subreg handling on vector mode

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

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

--- Comment #2 from JuzheZhong  ---
Add more test:

void matrix_4x4_transpose_segmented_load(float* dst, float* src)
{
vfloat32m1x4_t data = __riscv_vlseg4e32_v_f32m1x4(src, 4);
vfloat32m1_t data0 = __riscv_vget_v_f32m1x4_f32m1(data, 0);
vfloat32m1_t data1 = __riscv_vget_v_f32m1x4_f32m1(data, 1);
vfloat32m1_t data2 = __riscv_vget_v_f32m1x4_f32m1(data, 2);
vfloat32m1_t data3 = __riscv_vget_v_f32m1x4_f32m1(data, 3);
vfloat32m4_t packedData = __riscv_vcreate_v_f32m1_f32m4(data0,
data1,
data2,
data3);
__riscv_vse32_v_f32m4(dst, packedData, 16);
}

matrix_4x4_transpose_segmented_load:
vsetivlizero,4,e32,m1,ta,ma
vlseg4e32.v v8,(a1)
vsetivlizero,16,e32,m4,ta,ma
vmv1r.v v4,v8
vmv1r.v v5,v9
vmv1r.v v6,v10
vmv1r.v v7,v11
vse32.v v4,0(a0)
ret

[Bug testsuite/113437] [14 Regression] gcc.dg/tree-ssa/pr95906.c fails on arm since g:6686e16fda4

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Hongtao Liu from comment #2)
> Maybe we can add target vect_int.

Not really because vect_int depends on the vect.exp framework still.  See PR
113418 and the emails linked from there.

[Bug testsuite/113437] [14 Regression] gcc.dg/tree-ssa/pr95906.c fails on arm since g:6686e16fda4

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

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

--- Comment #2 from Hongtao Liu  ---
Maybe we can add target vect_int.

[Bug modula2/111956] [14 Regression] Many powerpc platforms do _not_ have support for IEEE754 long double

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

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

--- Comment #20 from Gaius Mulley  ---
Created attachment 57123
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57123=edit
ChangeLog for proposed fix

For completeness here is the changelog.

[Bug rust/113461] [14 Regression] rust-proc-macro.cc:174:15: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Werror=format=]

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-01-18
   Keywords||build

--- Comment #1 from Andrew Pinski  ---
Confirmed, this was also reported on IRC.
I think there will be a patch pushed in the next day or so too to fix this.

[Bug modula2/111956] [14 Regression] Many powerpc platforms do _not_ have support for IEEE754 long double

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

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

Gaius Mulley  changed:

   What|Removed |Added

  Attachment #56522|0   |1
is obsolete||
  Attachment #56524|0   |1
is obsolete||
  Attachment #57110|0   |1
is obsolete||

--- Comment #19 from Gaius Mulley  ---
Created attachment 57122
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57122=edit
Proposed fix

Here is the proposed fix - which in addition to the previous work in progress
patch implements -mabi= options.   Many thanks for all the hints.  I'll post it
to gcc patches as suggested above.

Seen it bootstrap on:

power8 
==

# of expected passes12974
# of unexpected failures18

power9
==

# of expected passes12992

x86_64
==

# of expected passes12992

[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

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

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

--- Comment #3 from Joseph S. Myers  ---
If you're linking with the version of the DFP arithmetic functions
(__bid_a3 etc.) in libdfp rather than the libgcc version - check the link
order carefully to make sure the right version is linked in - and they're not
respecting the rounding mode, that would be a libdfp issue, not a GCC one. If
you're doing arithmetic with constant operands, it might be folded at compile
time; make sure you're using -frounding-math to avoid that.

[Bug c++/112588] [modules] ICE in make_decl_rtl when returning str literal when string header imported in module

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:3471a61ed0ddef70de8f1bbba85cd1e945fc86fd

commit r14-8196-g3471a61ed0ddef70de8f1bbba85cd1e945fc86fd
Author: Nathaniel Shead 
Date:   Sat Dec 16 21:34:45 2023 +1100

c++: Prevent overwriting arguments when merging duplicates [PR112588]

When merging duplicate instantiations of function templates, currently
read_function_def overwrites the arguments with that of the existing
duplicate. This is problematic, however, since this means that the
PARM_DECLs in the body of the function definition no longer match with
the PARM_DECLs in the argument list, which causes issues when it comes
to generating RTL.

There doesn't seem to be any reason to do this replacement, so this
patch removes that logic.

PR c++/112588

gcc/cp/ChangeLog:

* module.cc (trees_in::read_function_def): Don't overwrite
arguments.

gcc/testsuite/ChangeLog:

* g++.dg/modules/merge-16.h: New test.
* g++.dg/modules/merge-16_a.C: New test.
* g++.dg/modules/merge-16_b.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

[newbie-02 at gmx dot de via Gcc-bugs]

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

--- Comment #2 from newbie-02  ---
(In reply to Joseph S. Myers from comment #1)  

hello and thank you very much!!,  
> The decimal rounding mode is set with fe_dec_setround.  

found in my directories that I already had experimented with that,  
a distinct include of libdfp/dfp/fenv.h made progress,  
but also with `fe_dec_setround(FE_DEC_TONEARESTFROMZERO)`,  
successful as `if ((r = fe_dec_getround()) == -1)` produces '4',  
the implicit rounding for the addition stays with 'to even'.  

:-(will continue research tomorrow.  

the strategic discussion is above my experience, from POV  
wanting an alternative for people fed up with bin-FP imprecision  
it would be:  
- good if it works,  
- is easy to find,  
- wouldn't require much 'info gathering' and configuration effort,

[Bug c++/113389] ICE when explicit object parameter is not declared as the first parameter

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
I have a patch.

[Bug rust/113461] New: [14 Regression] rust-proc-macro.cc:174:15: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Werror=format=]

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

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

Bug ID: 113461
   Summary: [14 Regression] rust-proc-macro.cc:174:15: error:
format '%lu' expects argument of type 'long unsigned
int', but argument 3 has type 'long long unsigned int'
[-Werror=format=]
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-linux*
Target: hppa*-*-linux*
 Build: hppa*-*-linux*

/home/dave/gnu/gcc/objdir/./prev-gcc/xg++
-B/home/dave/gnu/gcc/objdir/./prev-gcc
/ -B/home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/bin/ -nostdinc++
-B/home/dave/g
nu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
 -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include 
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-fno-PIE -c  -DIN_GCC_FRONTEND -g -O2 -fno-checking -DIN_GCC-fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -Wno-unused-parameter   -DHAVE_CONFIG_H
-fno-PIE -I. -Irust -I../../gcc/gcc -I../../gcc/gcc/rust
-I../../gcc/gcc/../include  -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc/gcc/../libbacktrace   -o rust/rust-macro-invoc-lexer.o -MT
rust/rust-macro-invoc-lexer.o -MMD -MP -MF
rust/.deps/rust-macro-invoc-lexer.TPo -g -O2 -fno-checking -I
../../gcc/gcc/rust -I ../../gcc/gcc/rust/lex -I ../../gcc/gcc/rust/parse -I
../../gcc/gcc/rust/ast -I ../../gcc/gcc/rust/analysis -I
../../gcc/gcc/rust/backend -I ../../gcc/gcc/rust/expand -I
../../gcc/gcc/rust/hir/tree -I ../../gcc/gcc/rust/hir -I
../../gcc/gcc/rust/resolve -I ../../gcc/gcc/rust/util -I
../../gcc/gcc/rust/typecheck -I ../../gcc/gcc/rust/checks/lints -I
../../gcc/gcc/rust/checks/errors -I ../../gcc/gcc/rust/checks/errors/privacy -I
../../gcc/gcc/rust/checks/errors/borrowck -I ../../gcc/gcc/rust/util -I
../../gcc/gcc/rust/metadata -I ../../gcc/gcc/../libgrust
../../gcc/gcc/rust/expand/rust-macro-invoc-lexer.cc
In file included from ../../gcc/gcc/rust/expand/rust-proc-macro.cc:18:
../../gcc/gcc/rust/expand/rust-proc-macro.cc: In function 'const
std::vector Rust::load_macros(std::string)':
../../gcc/gcc/rust/expand/rust-proc-macro.cc:174:15: error: format '%lu'
expects argument of type 'long unsigned int', but argument 3 has type 'long
long unsigned int' [-Werror=format=]
  174 |   rust_debug ("Found %lu procedural macros", array->length);
  |   ^  ~
  | |
  | long long unsigned
int
../../gcc/gcc/rust/rust-diagnostics.h:305:57: note: in definition of macro
'rust_debug'
  305 | #define rust_debug(...) rust_debug_loc (UNDEF_LOCATION, __VA_ARGS__)
  | ^~~
../../gcc/gcc/rust/expand/rust-proc-macro.cc:174:24: note: format string is
defined here
  174 |   rust_debug ("Found %lu procedural macros", array->length);
  |  ~~^
  ||
  |long unsigned int
  |  %llu

[Bug target/113429] RISC-V: SPEC2017 527 cam4 miscompilation in autovec VLA build

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

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

--- Comment #8 from Vineet Gupta  ---
Thx for the quick fix. I'll validate and commit !

[Bug target/113429] RISC-V: SPEC2017 527 cam4 miscompilation in autovec VLA build

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

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

--- Comment #7 from JuzheZhong  ---
I have fixed patch which is approved:
https://patchwork.sourceware.org/project/gcc/patch/20240117143151.3812116-1-juzhe.zh...@rivai.ai/

Could you commit it for me and test CAM4 again ?

Or you are not able to commit it, I can ask Li Pan commit it later.

Thanks.

[Bug middle-end/111659] document that -Wstrict-flex-arrays depends on -ftree-vrp

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from sandra at gcc dot gnu.org ---
Fixed.

[Bug middle-end/111659] document that -Wstrict-flex-arrays depends on -ftree-vrp

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Sandra Loosemore :

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

commit r14-8195-geb71695f76378151cb38372051bf50aed792f36d
Author: Sandra Loosemore 
Date:   Wed Jan 17 21:37:19 2024 +

Clean up documentation for -Wstrict-flex-arrays [PR111659]

gcc/ChangeLog
PR middle-end/111659
* doc/extend.texi (Common Variable Attributes): Fix long lines
in documentation of strict_flex_array + other minor copy-editing.
Add a cross-reference to -Wstrict-flex-arrays.
* doc/invoke.texi (Option Summary): Fix whitespace in tables
before -fstrict-flex-arrays and -Wstrict-flex-arrays.
(C Dialect Options): Combine the docs for the two
-fstrict-flex-arrays forms into a single entry.  Note this option
is for C/C++ only.  Add a cross-reference to -Wstrict-flex-arrays.
(Warning Options): Note -Wstrict-flex-arrays is for C/C++ only.
Minor copy-editing.  Add cross references to the strict_flex_array
attribute and -fstrict-flex-arrays option.  Add note that this
option depends on -ftree-vrp.

[Bug c++/112632] [14 Regression] Non-type template parameter created with converting constructor sometimes has original type

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/113221] [14 Regression][aarch64]ICE in extract_insn, at recog.cc:2812 since r14-6605-gc0911c6b357ba9

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug target/113221] [14 Regression][aarch64]ICE in extract_insn, at recog.cc:2812 since r14-6605-gc0911c6b357ba9

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

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

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

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

commit r14-8194-g7a8124e341aebcc544b4720e920b625f4ffe4e8a
Author: Andrew Pinski 
Date:   Tue Jan 16 15:37:49 2024 -0800

aarch64: Fix aarch64_ldp_reg_operand predicate not to allow all subreg
[PR113221]

So the problem here is that aarch64_ldp_reg_operand will all subreg even
subreg of lo_sum.
When LRA tries to fix that up, all things break. So the fix is to change
the check to only
allow reg and subreg of regs.

Note the tendancy here is to use register_operand but that checks the mode
of the register
but we need to allow a mismatch modes for this predicate for now.

Built and tested for aarch64-linux-gnu with no regressions
(Also tested with the LD/ST pair pass back on).

PR target/113221

gcc/ChangeLog:

* config/aarch64/predicates.md (aarch64_ldp_reg_operand): For
subreg,
only allow REG operands instead of allowing all.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/pr113221-1.c: New test.

Signed-off-by: Andrew Pinski 

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-01-17

--- Comment #1 from Jonathan Wakely  ---
I assume that int8_t is char on Solaris, rather than signed char?

Formatting a char behaves differently from signed char, and other integral
types.

I think this will fix it:

--- a/libstdc++-v3/testsuite/std/format/functions/format.cc
+++ b/libstdc++-v3/testsuite/std/format/functions/format.cc
@@ -365,7 +365,7 @@ test_minmax()
 s = std::format("{:b}" , std::numeric_limits::max());
 VERIFY( s == '1' + ones );
   };
-  check(std::int8_t(0));
+  check(std::make_signed_t(0));
   check(std::int16_t(0));
   check(std::int32_t(0));
   check(std::int64_t(0));


That causes the lambda to use signed char instead of char, and that is
formatted as an integer not a character.

[Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest

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

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

--- Comment #6 from Jonathan Wakely  ---
Oh I think I misread it ... it does enable some internal assertions, but is
mostly the same meaning as our debug mode.

[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses

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

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

Bug 94629 Summary: 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629

   What|Removed |Added

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

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #26 from Martin Jambor  ---
(In reply to Martin Liška from comment #25)
> No, there's still the 'ipa_polymorphic_call_context::set_by_invariant' issue
> that's waiting for Honza.

Finally fixed with:

https://gcc.gnu.org/g:4f4820964ebffc03249d98239a4ad2b43dd1a486

commit r14-8191-g4f4820964ebffc03249d98239a4ad2b43dd1a486
Author: Jan Hubicka 
Date:   Wed Jan 17 19:16:47 2024 +0100

Remove accidental hack in ipa_polymorphic_call_context::set_by_invariant

I managed to commit a hack setting offset to 0 in
ipa_polymorphic_call_context::set_by_invariant.  This makes it to give up
on multiple
inheritance, but most likely won't give bad code since the ohter base will
be of
different type.

gcc/ChangeLog:

* ipa-polymorphic-call.cc
(ipa_polymorphic_call_context::set_by_invariant): Remove
accidental hack reseting offset.

[Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest

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

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

--- Comment #5 from Jonathan Wakely  ---
It's a shame they're using "debug mode" to mean "debug the library impl itself"
when that's a term we have been using with completely different meaning for
many years.

[Bug c++/113457] Trying to emulate views::concat with std::generator gives ICE on co_yield: "internal compiler error: in canonicalize_component_ref, at gimplify.cc"

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

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

--- Comment #4 from Jonathan Wakely  ---
Created attachment 57121
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57121=edit
Gzipped preprocessed source

This ICEs with current trunk, and r14-1 and r13-1 with this error:

gen.cc:14:10: internal compiler error: in canonicalize_component_ref, at
gimplify.cc:3153

With r12-1 it's a bit different, but still ICEs:

/home/jwakely/gcc/14/include/c++/14.0.1/ranges:6116:30: internal compiler
error: in enforce_access, at cp/semantics.c:366

However, anything older than GCC 14.0.0 gives dozens of errors about new C++23
features that aren't understood, so I'm not sure how meaningful anything above
is. It needs reducing.

[Bug tree-optimization/113458] Missed SLP for reduction of multiplication/addition with promotion

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

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

--- Comment #1 from Andrew Pinski  ---
The loop based vectorizer is able to do a decent job at:
```
int f(short *a, signed char *b, int n)
{
int sum = 0;
n = 8;
for(int i = 0;i < n; i++)
  sum += a[i]*b[i];
return sum;
}
```

But if we reduce n to 4, the loop based vectorizer is not able to handle it
either.

[Bug c++/113457] Trying to emulate views::concat with std::generator gives ICE on co_yield: "internal compiler error: in canonicalize_component_ref, at gimplify.cc"

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

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

--- Comment #3 from Jonathan Wakely  ---
A little less than a month ago, Dec 21.

I'm trying to bisect it. A slightly modified copy of trunk headers (to remove
the use of explicit object member functions) compiles with GCC 13.1 but ICEs
with the releases/gcc-13 branchpoint, so might be an ice-with-checking

GCC 13.1 with -std=c++23 -fchecking=3 bails out with:

gen.cc: In function 'void concat(concat&,
const std::vector >&, const std::array&>(const std::initializer_list&, const std::vector >&, const std::array&)::_Z6concatIJRKSt16initializer_listIiERKSt6vectorIiSaIiEERKSt5arrayIdLm3St9generatorIddvEDpOT_.Frame*)':
gen.cc:12:1: error: type mismatch in 'component_ref'
   12 | concat(Ranges&&... ranges) -> generator
  | ^~
struct _Recursive_awaiter

struct _Recursive_awaiter

gen.cc:12:1: error: invalid LHS in gimple call
frame_ptr->Yd0_2_3 = std::__gen::_Promise_erased::yield_value&,
std::allocator > (_15, _16); [return slot optimization]
gen.cc:12:1: error: type mismatch in 'component_ref'
struct _Recursive_awaiter

struct _Recursive_awaiter

gen.cc:12:1: error: invalid LHS in gimple call
frame_ptr->Yd0_2_3 = std::__gen::_Promise_erased::yield_value >&,
std::allocator > (_23, _24); [return slot optimization]
gen.cc:12: confused by earlier errors, bailing out



I'll attach the .ii I'm using.

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
   Last reconfirmed||2024-01-17

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

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

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

--- Comment #3 from Iain Sandoe  ---
OK. So I realise the reason you see this and I wasn't: I have the habit of
installing before running the testsuite.  When I test uninstalled, then I get
the issue.

... the subsequent work reveals that we are not setting the
"ENABLE_DARWIN_AT_RPATH" in gcc/site.exp.  Somehow an AC_SUBST has been dropped
on the way.  However, that is actually fixable with a small change to
gcc/Makefile.in.


... then we have to add -Bpath/to/libatomic/.libs conditionally on
ENABLE_DARWIN_AT_RPATH (in gfortran.exp) (not hard since ENABLE_DARWIN_AT_RPATH
is a global)

Now I have a concern that we have instances of -Bpath/to/libsomething/.libs
that are present to allow for specs substitution and we also need them for
providing run paths at test time.  BUT, we do not want duplicates (since, that
triggers a different warning for some Xcode versions, and is inefficient anyway
- albeit probably a very minor contribution to testing time).

So I think that gcc/lib/gfortran.exp needs to have the library -B/-L additions
structured so that only one set gets added.  I'll draft a patch for you to try.

[Bug c++/113457] Trying to emulate views::concat with std::generator gives ICE on co_yield: "internal compiler error: in canonicalize_component_ref, at gimplify.cc"

[dboles.src at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Daniel Boles  ---
Yeah, std::generator is new for GCC/libstdc++ v14. I think it landed a month or
two ago. I'm just getting started using it now. Getting in early bug-finding :)

[Bug libstdc++/113460] New: Segfault in __builtin_coro_destroy when using std::generator to concate ranges

[dboles.src at gmail dot com via Gcc-bugs]

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

Bug ID: 113460
   Summary: Segfault in __builtin_coro_destroy when using
std::generator to concate ranges
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dboles.src at gmail dot com
  Target Milestone: ---

Created attachment 57120
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57120=edit
.ii, .o, .s files

Using

   g++ (Debian 20240101-1) 14.0.0 20240101 (experimental) [master
r14-6875-g3a7dd24eade] 

Running this:

```cpp
#include 
#include 
#include 
#include 

using namespace std;

template 
[[nodiscard]] auto
concat(Ranges&&... ranges) -> generator
{
(co_yield ranges::elements_of(ranges), ...);
}

auto
main() -> int
{
auto const numbers1 = array{0};
auto const numbers2 = vector{0};
for (auto const _: concat(numbers1, numbers2) ) {}
}
```

gives this:

```none
Program received signal SIGSEGV, Segmentation fault.
0x00403e8e in std::__n4861::coroutine_handle >::promise_type>::destroy (this=0x41c320) at
/usr/lib/gcc-snapshot/include/c++/14/coroutine:244
244   void destroy() const { __builtin_coro_destroy(_M_fr_ptr); }
(ins)(gdb) bt
#0  0x00403e8e in std::__n4861::coroutine_handle >::promise_type>::destroy
(this=0x41c320) at /usr/lib/gcc-snapshot/include/c++/14/coroutine:244
#1  0x0040367c in std::generator >::~generator (this=0x41c320, 
__in_chrg=) at
/usr/lib/gcc-snapshot/include/c++/14/generator:700
#2  0x00402cd0 in std::__gen::_Promise_erased::_Recursive_awaiter > >::~_Recursive_awaiter (this=0x41c320,
__in_chrg=) at
/usr/lib/gcc-snapshot/include/c++/14/generator:360
#3  0x00401b8a in
concat(_Z6concatITpTkNSt6ranges11input_rangeEJRKSt5arrayIiLm1EERKSt6vectorIiSaIiSt9generatorIiivEDpOT_.Frame
*) (frame_ptr=0x41c2d0) at concatWC.cpp:13
#4  0x0040186f in
operator()(_ZZNSt5__gen15_Promise_erasedIRKiE11yield_valueIRKSt6vectorIiSaIiEESaISt4byteEEEDaNSt6ranges11elements_ofIT_T0_EEENKUlSt15allocator_arg_tSB_N9__gnu_cxx17__normal_iteratorIPS1_S7_EESL_E_clESH_SB_SL_SL_.Frame
*) (frame_ptr=0x41c3e0)
at /usr/lib/gcc-snapshot/include/c++/14/generator:160
#5  0x0040409b in
std::__n4861::coroutine_handle
>::resume (this=0x41c2e0)
at /usr/lib/gcc-snapshot/include/c++/14/coroutine:242
#6  0x00403b62 in std::generator::_Iterator::_M_next
(this=0x7fffdd58)
at /usr/lib/gcc-snapshot/include/c++/14/generator:793
#7  0x004032e6 in std::generator::_Iterator::operator++
(this=0x7fffdd58)
at /usr/lib/gcc-snapshot/include/c++/14/generator:767
#8  0x004012e4 in main () at concatWC.cpp:20
(ins)(gdb) 
```

Outputs of -freport-bug -save-temps are attached. Let me know if I can help
with any more info.

Thanks for implementing std::generator and all the other work on GCC and C++!

[Bug c++/113457] Trying to emulate views::concat with std::generator gives ICE on co_yield: "internal compiler error: in canonicalize_component_ref, at gimplify.cc"

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-01-17
   Keywords||needs-bisection,
   ||needs-reduction
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Confirmed.

GCC 13 says "fatal error: generator: No such file or directory" so I don't know
if it's a regression or not.

[Bug tree-optimization/113459] New: ICE: in as_a, at machmode.h:381 with memset() on a _BitInt() at -O1 and above

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113459
   Summary: ICE: in as_a, at machmode.h:381 with memset() on a
_BitInt() at -O1 and above
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57119
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57119=edit
reduced testcase

Compiler output:
$ cc1 -quiet -O testcase.c 
during GIMPLE pass: fre
testcase.c: In function 'foo':
testcase.c:8:1: internal compiler error: in as_a, at machmode.h:381
8 | }
  | ^
0x876149 scalar_int_mode as_a(machine_mode)
/repo/gcc-trunk/gcc/machmode.h:381
0x876149 scalar_int_mode as_a(machine_mode)
/repo/gcc-trunk/gcc/machmode.h:379
0x876149 vn_reference_lookup_3
/repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:2972
0x16226f7 walk_non_aliased_vuses(ao_ref*, tree_node*, bool, void* (*)(ao_ref*,
tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*, translate_flags*),
tree_node* (*)(tree_node*), unsigned int&, void*)
/repo/gcc-trunk/gcc/tree-ssa-alias.cc:3914
0x171a4ef vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*, bool)
/repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:4023
0x171e7e7 visit_reference_op_load
/repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:5740
0x171e7e7 visit_stmt
/repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:6261
0x171ee6b process_bb
/repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:8025
0x1720846 do_rpo_vn_1
/repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:8626
0x17223bb execute
/repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:8787
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ xgcc -v
Using built-in specs.
COLLECT_GCC=/repo/build-gcc-trunk-amd64A/gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8193-20240117105849-g3340878009a-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240117 (experimental) (GCC)

[Bug tree-optimization/113458] New: Missed SLP for reduction of multiplication/addition with promotion

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

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

Bug ID: 113458
   Summary: Missed SLP for reduction of multiplication/addition
with promotion
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-*

Take:
```
int f(short *a, signed char *b)
{
int sum = 0;
sum += a[0]*b[0];
sum += a[1]*b[1];
sum += a[2]*b[2];
sum += a[3]*b[3];
return sum;
}
```

This is not SLPed with GCC.

With `-fno-vect-cost-model` it is but in a very inefficient way.

LLVM produces:
```
ldr s0, [x1]
ldr d1, [x0]
sshll   v0.8h, v0.8b, #0 // promote to short
smull   v0.4s, v0.4h, v1.4h //multiply 2 shorts to ints
addvs0, v0.4s // do the reduction
fmovw0, s0
```

Which GCC should be to produce this too.

[Bug c++/113457] New: Trying to emulate views::concat with std::generator gives ICE on co_yield: "internal compiler error: in canonicalize_component_ref, at gimplify.cc"

[dboles.src at gmail dot com via Gcc-bugs]

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

Bug ID: 113457
   Summary: Trying to emulate views::concat with std::generator
gives ICE on co_yield: "internal compiler error: in
canonicalize_component_ref, at gimplify.cc"
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dboles.src at gmail dot com
  Target Milestone: ---

Created attachment 57118
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57118=edit
.ii and .s files

I'm using Debian's snapshot:

g++ (Debian 20240101-1) 14.0.0 20240101 (experimental) [master
r14-6875-g3a7dd24eade]

I don't see any likely / still-open dupes, but of course I'm happy if this was
already reported! But in case not...

I'm trying to implement a simple `views::concat` analog by following this
answer:

* https://stackoverflow.com/a/76869567

The answer is a bit limited in real-world use, as we should be able to mix
ranges of different-but-compatible value types. So in reality we'd use
common_reference_t, common_type_t, etc. - but for this repro I simplify by
mixing ranges of either int or double values, to a std::generator:

```cpp
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std;

template 
[[nodiscard]] auto
concat(Ranges&&... ranges) -> generator
{
(co_yield ranges::elements_of(ranges), ...);
}

auto
main() -> int
{
auto const numbers1 = {4, 8, 15, 16, 23, 42};
auto const numbers2 = vector{11, 22, 77, 99};
auto const numbers3 = array{0.5, 1.0, 1.333};
return *concat(numbers1, numbers2, numbers3).begin();
}
```

This ICEs as follows:

```none
concatICE.cpp: In function 'void concat(concat&, const std::vector >&,
const std::array&>(const std::initializer_list&, const
std::vector >&, const std::array&)::_Z6concatITpTkNSt6ranges11input_rangeEJRKSt16initializer_listIiERKSt6vectorIiSaIiEERKSt5arrayIdLm3St9generatorIddvEDpOT_.Frame*)':
concatICE.cpp:14:10: internal compiler error: in canonicalize_component_ref, at
gimplify.cc:3153
   14 | (co_yield ranges::elements_of(ranges), ...);
  |  ^~~~
0x93a07c canonicalize_component_ref(tree_node**) [clone .isra.0]
../../src/gcc/gimplify.cc:3153
0x1e0d70d gimplify_compound_lval
../../src/gcc/gimplify.cc:3570
0x1d76e41 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/gcc/gimplify.cc:17722
0x1dd275d gimplify_addr_expr
../../src/gcc/gimplify.cc:6811
0x1d76f99 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/gcc/gimplify.cc:17817
0x1e2b958 gimplify_expr
../../src/gcc/gimplify.cc:18839
0x1e2b958 gimplify_arg(tree_node**, gimple**, unsigned int, bool)
../../src/gcc/gimplify.cc:3748
0x20b22ed cp_gimplify_arg
../../src/gcc/cp/cp-gimplify.cc:582
0x1ea2994 cp_gimplify_expr(tree_node**, gimple**, gimple**)
../../src/gcc/cp/cp-gimplify.cc:852
0x1d76ba1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/gcc/gimplify.cc:17679
0x1d774a8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/gcc/gimplify.cc:18547
0x1d864e3 gimplify_modify_expr
../../src/gcc/gimplify.cc:6402
0x1d76f7c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/gcc/gimplify.cc:17770
0x1eeac68 gimplify_stmt(tree_node**, gimple**)
../../src/gcc/gimplify.cc:7477
0x1eeac68 gimplify_cleanup_point_expr
../../src/gcc/gimplify.cc:7215
0x1d77a44 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/gcc/gimplify.cc:18163
0x1dc3162 gimplify_cond_expr
../../src/gcc/gimplify.cc:4713
0x1d77a5d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/gcc/gimplify.cc:17727
0x1d77ad0 gimplify_stmt(tree_node**, gimple**)
../../src/gcc/gimplify.cc:7477
0x1d77ad0 gimplify_statement_list
../../src/gcc/gimplify.cc:
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

shell returned 1
```

The save-temps output is attached.

Thanks for any help and all the amazing work on GCC and C++!

[Bug libgomp/113448] libgomp.c/alloc-pinned-1.c etc. XPASS

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

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #1 from John David Anglin  ---
Same issue observed on hppa64-hp-hpux11.11.

[Bug bootstrap/113445] [14 Regression] bootstrap failure on f95-lang.cc: ‘-fcompare-debug’ failure since r14-8174

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

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

[Bug bootstrap/113456] [14 Regression] Bootstrap comparison failure!

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug bootstrap/113456] New: [14 Regression] Bootstrap comparison failure!

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 113456
   Summary: [14 Regression] Bootstrap comparison failure!
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: linux-i686

On Linux/i686, r14-8174-g0c42d1782e48d8 caused:

Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/range-op.o differs
make[5]: *** [Makefile:25730: compare] Error 1

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

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

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

--- Comment #2 from Maciej W. Rozycki  ---
(In reply to Sam James from comment #1)
> Didn't help this time ;)

Well, now it mentions 483.xalancbmk, which the other bug does not
(and which I searched for specifically, finding only a bunch of old
reports).

[Bug c++/113242] g++ rejects-valid template argument of class type containing an lvalue reference

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:68cea2d32a9fd525154b6a48042e5835d4c5e371

commit r14-8189-g68cea2d32a9fd525154b6a48042e5835d4c5e371
Author: Patrick Palka 
Date:   Wed Jan 17 13:01:01 2024 -0500

c++: address of class NTTP object as targ [PR113242]

invalid_tparm_referent_p was rejecting using the address of a class NTTP
object as a template argument, but this should be fine.

PR c++/113242
PR c++/99493

gcc/cp/ChangeLog:

* pt.cc (invalid_tparm_referent_p) : Suppress
DECL_ARTIFICIAL rejection test for class NTTP objects.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nontype-class61.C: New test.
* g++.dg/cpp2a/nontype-class62.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/99493] Address of template parameter object is not a valid template argument

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:68cea2d32a9fd525154b6a48042e5835d4c5e371

commit r14-8189-g68cea2d32a9fd525154b6a48042e5835d4c5e371
Author: Patrick Palka 
Date:   Wed Jan 17 13:01:01 2024 -0500

c++: address of class NTTP object as targ [PR113242]

invalid_tparm_referent_p was rejecting using the address of a class NTTP
object as a template argument, but this should be fine.

PR c++/113242
PR c++/99493

gcc/cp/ChangeLog:

* pt.cc (invalid_tparm_referent_p) : Suppress
DECL_ARTIFICIAL rejection test for class NTTP objects.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nontype-class61.C: New test.
* g++.dg/cpp2a/nontype-class62.C: New test.

Reviewed-by: Jason Merrill 

[Bug testsuite/113446] [14 Regression] gcc.dg/tree-ssa/scev-16.c FAILs

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-01-17
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=113418
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #2)
> FAILs on i686-linux too.
> I'd say the error is that the test is placed in incorrect directory,
> vect_int effective targets only makes sense in */vect/ where the *.exp files
> add extra flags needed for the vectorization.

Oh yes it was noticed by others too and reported a broader bug about the use of
vect_* effective targets, see PR 113418; there is a list there too.

[Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest

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

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

--- Comment #4 from Sam James  ---
libcxx has started working towards this, see
https://discourse.llvm.org/t/rfc-hardening-in-libc/73925 and
https://libcxx.llvm.org/Hardening.html.

[Bug c++/111544] [14 regression] assignment of read-only location after r14-4111-g6e92a6a2a72d3b

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

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

Sam James  changed:

   What|Removed |Added

 CC||macro at orcam dot me.uk

--- Comment #15 from Sam James  ---
*** Bug 113454 has been marked as a duplicate of this bug. ***

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

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #1 from Sam James  ---
(In reply to Maciej W. Rozycki from comment #0)
> Filing this bug then for the C++ experts to decide, and if nothing else for
> posterity, so that the next person who comes across this build failure can
> find it and save themselves from repeating my investigation.

Didn't help this time ;)

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

[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

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

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

--- Comment #1 from Joseph S. Myers  ---
The decimal rounding mode is set with fe_dec_setround.  libdfp provides that
function and an fenv.h wrapper with constant definitions including
FE_DEC_TONEARESTFROMZERO.  Providing that library is outside the scope of GCC;
see https://sourceware.org/pipermail/libc-alpha/2019-September/106579.html for
a discussion of considerations for any integration of such support directly in
glibc (which would certainly be a lot of work).

libdfp is at https://github.com/libdfp/libdfp but doesn't have that much
activity.