[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

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

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

--- Comment #16 from Eric Botcazou  ---
> Why use STACK_REALIGN_DEFAULT rather than PREFERRED_STACK_BOUNDARY_DEFAULT?

We know that it works since Solaris has used it for ages, so this alternate way
could be deemed riskier.  But no strong opinion, if the consensus is to use the
latter, then so be it.

[Bug target/112760] New: [14 Regression] wrong code with -O2 -fno-dce -fno-guess-branch-probability -m8bit-idiv -mavx --param=max-cse-insns=0 and __builtin_add_overflow_p()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112760
   Summary: [14 Regression] wrong code with -O2 -fno-dce
-fno-guess-branch-probability -m8bit-idiv -mavx
--param=max-cse-insns=0 and __builtin_add_overflow_p()
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: i686-pc-linux-gnu

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

Output:
$ x86_64-pc-linux-gnu-gcc -m32 -O2 -fno-dce -fno-guess-branch-probability
-m8bit-idiv -mavx --param=max-cse-insns=0 testcase.c
$ ./a.out 
Aborted

The code for __builtin_add_overflow() check looks wrong:
# testcase.c:9:   u16 x = __builtin_add_overflow_p (a, g, (u16) 0);
add eax, ecx# tmp110, g.0_1
mov eax, 1  # tmp118,
setcbl  #, _8
cmovne  ebx, eax# _8,, _8, tmp118

Comparing the code without -mavx, the breakage can be observed better:
$ diff -u a-testcase.GOOD.s a-testcase.BAD.s 
--- a-testcase.GOOD.s   2023-11-29 08:34:39.978807709 +0100
+++ a-testcase.BAD.s2023-11-29 08:32:27.458809580 +0100
@@ -4,7 +4,7 @@
 #  compiled by GNU C version 14.0.0 20231128 (experimental), GMP version
6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP

 # GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
-# options passed: -m32 -m8bit-idiv -masm=intel -mtune=generic -march=x86-64
-O2 -fno-dce -fno-guess-branch-probability --param=max-cse-insns=0
+# options passed: -m32 -m8bit-idiv -mavx -masm=intel -mtune=generic
-march=x86-64 -O2 -fno-dce -fno-guess-branch-probability
--param=max-cse-insns=0
.text
.p2align 4
.globl  foo0
@@ -28,10 +28,8 @@
movzx   esi, WORD PTR [esp+16]  # b, b
 # testcase.c:9:   u16 x = __builtin_add_overflow_p (a, g, (u16) 0);
add eax, ecx# tmp110, g.0_1
-   movzx   edx, ax # tmp111, tmp110
-   setcbl  #, _8
-   cmp eax, edx# tmp110, tmp111
mov eax, 1  # tmp118,
+   setcbl  #, _8
cmovne  ebx, eax# _8,, _8, tmp118
 # testcase.c:10:   g -= g / b;
mov eax, ecx# tmp119, g.0_1


The "cmovne" instruction is using the Z flag from a different comparison.



$ 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-5940-20231128183456-g3d104d93a70-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/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
--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-5940-20231128183456-g3d104d93a70-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231128 (experimental) (GCC)

[Bug driver/112759] [13 regression] mips -march=native detection broken with gcc 13+

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

matoro  changed:

   What|Removed |Added

 CC||matoro_gcc_bugzilla@matoro.
   ||tk

--- Comment #1 from matoro  ---
Created attachment 56714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56714=edit
/proc/cpuinfo

[Bug driver/112759] New: [13 regression] mips -march=native detection broken with gcc 13+

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

Bug ID: 112759
   Summary: [13 regression] mips -march=native detection broken
with gcc 13+
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matoro_gcc_bugzilla at matoro dot tk
  Target Milestone: ---

Since gcc 13 - and presumably 66c48be23e0fa5ee7474b4b078e013f901c71eed since
that is the only recent change to this area - detection of -march=native on
mips is broken, defaulting to mips1.

With gcc 13:
# gcc -march=native -Q --help=target | grep "arch=" | head -n 1
  -march=ISAmips1
# gcc --version
gcc (Gentoo 13.2.1_p20231014 p9) 13.2.1 20231014

With gcc 12:
# gcc -march=native -Q --help=target | grep "arch=" | head -n 1
  -march=ISAocteon2
# gcc --version
gcc (Gentoo 12.3.1_p20230825 p2) 12.3.1 20230825

Contents of my /proc/cpuinfo are attached.  strace seems to indicate that it is
reading the data at least:

openat(AT_FDCWD, "/proc/cpuinfo", O_RDONLY) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH,
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0,
stx_mode=S_IFREG|0444, stx_size=0, ...}) = 0
read(3, "system type\t\t: EBB6800 (CN6880p2"..., 1024) = 1024
close(3)= 0

[Bug target/112578] LoongArch: Wrong code -with -mlsx -fno-fp-int-builtin-inexact

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #6 from Xi Ruoyao  ---
Fixed for trunk.

[Bug target/112578] LoongArch: Wrong code -with -mlsx -fno-fp-int-builtin-inexact

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Xi Ruoyao :

https://gcc.gnu.org/g:530348c418d9ec28aac5b151c15405bfb860e5c4

commit r14-5950-g530348c418d9ec28aac5b151c15405bfb860e5c4
Author: Xi Ruoyao 
Date:   Sat Nov 18 04:48:20 2023 +0800

LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

The usage LSX and LASX frint/ftint instructions had some problems:

1. These instructions raises FE_INEXACT, which is not allowed with
   -fno-fp-int-builtin-inexact for most C2x section F.10.6 functions
   (the only exceptions are rint, lrint, and llrint).
2. The "frint" instruction without explicit rounding mode is used for
   roundM2, this is incorrect because roundM2 is defined "rounding
   operand 1 to the *nearest* integer, rounding away from zero in the
   event of a tie".  We actually don't have such an instruction.  Our
   frintrne instruction is roundevenM2 (unfortunately, this is not
   documented).
3. These define_insn's are written in a way not so easy to hack.

So I removed these instructions and created a "simd.md" file, then added
them and the corresponding expanders there.  The advantage of the
simd.md file is we don't need to duplicate the RTL template twice (in
lsx.md and lasx.md).

gcc/ChangeLog:

PR target/112578
* config/loongarch/lsx.md (UNSPEC_LSX_VFTINT_S,
UNSPEC_LSX_VFTINTRNE, UNSPEC_LSX_VFTINTRP,
UNSPEC_LSX_VFTINTRM, UNSPEC_LSX_VFRINTRNE_S,
UNSPEC_LSX_VFRINTRNE_D, UNSPEC_LSX_VFRINTRZ_S,
UNSPEC_LSX_VFRINTRZ_D, UNSPEC_LSX_VFRINTRP_S,
UNSPEC_LSX_VFRINTRP_D, UNSPEC_LSX_VFRINTRM_S,
UNSPEC_LSX_VFRINTRM_D): Remove.
(ILSX, FLSX): Move into ...
(VIMODE): Move into ...
(FRINT_S, FRINT_D): Remove.
(frint_pattern_s, frint_pattern_d, frint_suffix): Remove.
(lsx_vfrint_, lsx_vftint_s__,
lsx_vftintrne_w_s, lsx_vftintrne_l_d, lsx_vftintrp_w_s,
lsx_vftintrp_l_d, lsx_vftintrm_w_s, lsx_vftintrm_l_d,
lsx_vfrintrne_s, lsx_vfrintrne_d, lsx_vfrintrz_s,
lsx_vfrintrz_d, lsx_vfrintrp_s, lsx_vfrintrp_d,
lsx_vfrintrm_s, lsx_vfrintrm_d,
v4sf2,
v2df2, round2,
fix_trunc2): Remove.
* config/loongarch/lasx.md: Likewise.
* config/loongarch/simd.md: New file.
(ILSX, ILASX, FLSX, FLASX, VIMODE): ... here.
(IVEC, FVEC): New mode iterators.
(VIMODE): ... here.  Extend it to work for all LSX/LASX vector
modes.
(x, wu, simd_isa, WVEC, vimode, simdfmt, simdifmt_for_f,
elebits): New mode attributes.
(UNSPEC_SIMD_FRINTRP, UNSPEC_SIMD_FRINTRZ, UNSPEC_SIMD_FRINT,
UNSPEC_SIMD_FRINTRM, UNSPEC_SIMD_FRINTRNE): New unspecs.
(SIMD_FRINT): New int iterator.
(simd_frint_rounding, simd_frint_pattern): New int attributes.
(_vfrint_): New
define_insn template for frint instructions.
   
(_vftint__):
Likewise, but for ftint instructions.
(2): New define_expand with
flag_fp_int_builtin_inexact checked.
(l2): Likewise.
(ftrunc2): New define_expand.  It does not require
flag_fp_int_builtin_inexact.
(fix_trunc2): New define_insn_and_split.  It does
not require flag_fp_int_builtin_inexact.
(include): Add lsx.md and lasx.md.
* config/loongarch/loongarch.md (include): Include simd.md,
instead of including lsx.md and lasx.md directly.
* config/loongarch/loongarch-builtins.cc
(CODE_FOR_lsx_vftint_w_s, CODE_FOR_lsx_vftint_l_d,
CODE_FOR_lasx_xvftint_w_s, CODE_FOR_lasx_xvftint_l_d):
Remove.

gcc/testsuite/ChangeLog:

PR target/112578
* gcc.target/loongarch/vect-frint.c: New test.
* gcc.target/loongarch/vect-frint-no-inexact.c: New test.
* gcc.target/loongarch/vect-ftint.c: New test.
* gcc.target/loongarch/vect-ftint-no-inexact.c: New test.

[Bug target/112753] [14 Regression] unrecognizable insn building glibc for s390x

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |14.0

[Bug testsuite/112751] [14 regression] gcc.target/powerpc/pcrel-sibcall-1.c fails after r14-5628-g53ba8d669550d3

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|target  |testsuite
   Target Milestone|--- |14.0

[Bug sanitizer/112748] memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||documentation
 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Component|middle-end  |sanitizer
   Last reconfirmed||2023-11-29

--- Comment #3 from Richard Biener  ---
Confirmed.  We fold all calls early after gimplification and folding is known
to also affect -O0.  This behavior is independent of sanitizing which happens
partly before and partly only after this folding takes place.

We also simplify 1 + 1 or x + 0 with -O0 or turn printf("%s", "Hello")
into puts("Hello") for example.

Documenting this behavior might be good.  Gating some of the simplifications
on optimization might be also reasonable.

[Bug target/112743] RISC-V: building FAIL with -march=rv64(or rv32)gc_zve32f_zvfh_zfh

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

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

--- Comment #4 from Li Pan  ---
There may be another ICE for zve32f, will double-check about the details.

[Bug target/112743] RISC-V: building FAIL with -march=rv64(or rv32)gc_zve32f_zvfh_zfh

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

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

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

https://gcc.gnu.org/g:25a51e98fdd504826a40775a5e5b9ffb336b5aa1

commit r14-5945-g25a51e98fdd504826a40775a5e5b9ffb336b5aa1
Author: Pan Li 
Date:   Wed Nov 29 14:31:30 2023 +0800

RISC-V: Bugfix for ICE in block move when zve32f

The exact_div requires the exactly multiple of the divider.
Unfortunately, the condition will be broken when zve32f in
some cases. For example,

potential_ew is 8
BYTES_PER_RISCV_VECTOR * lmul1 is [4, 4]

This patch would like to ensure the precondition of exact_div
when get_vec_mode.

PR target/112743

gcc/ChangeLog:

* config/riscv/riscv-string.cc (expand_block_move): Add
precondition check for exact_div.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112743-1.c: New test.

Signed-off-by: Pan Li 

[Bug target/112751] [14 regression] gcc.target/powerpc/pcrel-sibcall-1.c fails after r14-5628-g53ba8d669550d3

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #2 from Kewen Lin  ---
(In reply to Andrew Pinski from comment #1)
> This is just a testsuite issue. The functions are currently marked as
> noinline.  You can either add -fno-ipa-vrp or mark them with noipa instead.
> I am not sure if noipa here is right due to having some ipa happening due to
> localization.

Thanks for looking into this, I just tested with noipa and confirmed it worked
well.

[Bug c/112758] New: Inconsistent Bitwise AND Operation Result between int and long long int on Different Optimization Levels in GCC Trunk

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

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

Bug ID: 112758
   Summary: Inconsistent Bitwise AND Operation Result between int
and long long int on Different Optimization Levels in
GCC Trunk
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guminb at ajou dot ac.kr
  Target Milestone: ---

Dear GCC Development Team,

I would like to report an inconsistency observed in the GCC RISC-V 64 version
14.0.0 when compiling code involving bitwise AND operations between an `int`
and a `long long int` variable under different optimization levels. The issue
appears when both operands are negative, with results varying significantly
between non-optimized and optimized compilations.

The proof of concept (PoC) code provided below demonstrates this issue. The
code performs a bitwise AND operation between a 32-bit integer with its high
bit set (`globalVar`) and a 64-bit long long integer (`localVar`), both
containing negative values. The expected result of the operation seems to
differ based on the optimization level used during compilation.

PoC Code:

```c
#include 

int globalVar = 0x8000; // 32-bit int with high bit set

int main () {
long long int localVar = 0xffFF00ff; // 64-bit long long int
printf("localVar: 0x%llx\\n", localVar);
printf("globalVar: 0x%llx\\n", (long long int)globalVar);
printf("Result: 0x%llx\\n", ((localVar) & ((long long int) (globalVar;
return 0;
}
```

Observed Results:

- With **`O0`** optimization, the result of the bitwise AND operation is as
expected (**`0x00ff8000`**).
- With **`O1`**, **`O2`**, **`O3`**, **`Os`**, **`Oz`** optimizations, the
result changes to **`0x8000`**.

Assembly Output:
The assembly output for -O0 and -O1 can be viewed at the following Compiler
Explorer link:

https://godbolt.org/z/fb33vWT7o

- The **`O0`** output shows the expected behavior with explicit casting and AND
operation.
- The **`O1`** output, however, omits the casting and AND operation, leading to
an unexpected result.

I suspect this might be related to how the compiler handles casting or the
bitwise operation under different optimization levels. This inconsistency could
potentially lead to unintended behavior in applications that rely on such
operations, especially when negative values are involved.

I appreciate your attention to this matter and look forward to any insights or
potential solutions you might provide.

Best regards,
[Gyumin Baek]

[Bug c++/101113] g++ thinks constructor suppressed by a requires clause is actually a bad copy constructor

[gcc at nospam dot scs.stanford.edu via Gcc-bugs]

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

David Mazières  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from David Mazières  ---
Sorry I should have closed this bug report a while ago when I said it wasn't a
bug.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[zfigura at codeweavers dot com via Gcc-bugs]

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

--- Comment #15 from Zeb Figura  ---
(In reply to Eric Botcazou from comment #14)
> > I'd say that
> > 
> > config/i386/cygming.h:#define STACK_REALIGN_DEFAULT TARGET_SSE
> > 
> > is a non-working "fix".  The appropriate default would be
> > -mincoming-stack-boundary=2.  MIN_STACK_BOUNDARY should already be 4, so
> > that leaves PREFERRED_STACK_BOUNDARY_DEFAULT is the way to go here.
> 
> This was a minimal fix to support SSE, but Solaris was indeed more radical:
> 
> sol2.h:#undef STACK_REALIGN_DEFAULT
> sol2.h:#define STACK_REALIGN_DEFAULT (TARGET_64BIT ? 0 : 1)
> 
> so we could just mimic it for Windows.

Why use STACK_REALIGN_DEFAULT rather than PREFERRED_STACK_BOUNDARY_DEFAULT?

[Bug testsuite/112729] gcc.target/i386/apx-interrupt-1.c etc. FAIL

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Hongyu Wang :

https://gcc.gnu.org/g:99fa0bfd63d97825c4221dcd3123940f1d0e6291

commit r14-5943-g99fa0bfd63d97825c4221dcd3123940f1d0e6291
Author: Hongyu Wang 
Date:   Tue Nov 28 11:24:01 2023 +0800

[i386] Fix push2pop2 test fail on non-linux target [PR112729]

On linux x86-64, -fomit-frame-pointer was by default enabled so the
push2pop2 tests cfi scans are based on it. On other target with
-fno-omit-frame-pointer the cfi scan will be wrong as the frame pointer
is pushed at first. Add -fomit-frame-pointer to these tests that related
to cfi scan.

gcc/testsuite/ChangeLog:

PR target/112729
* gcc.target/i386/apx-interrupt-1.c: Add -fomit-frame-pointer.
* gcc.target/i386/apx-push2pop2-1.c: Likewise.
* gcc.target/i386/apx-push2pop2_force_drap-1.c: Likewise.

[Bug target/112757] RISC-V regression testsuite errors with rv32gcv_zvl1024b

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
See also:
rv32_zvl128b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112754
rv32_zvl256b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112755
rv32_zvl512b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112756
rv32_zvl1024b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112757

[Bug target/112755] RISC-V regression testsuite errors with rv32gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
See also:
rv32_zvl128b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112754
rv32_zvl256b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112755
rv32_zvl512b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112756
rv32_zvl1024b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112757

[Bug target/112756] RISC-V regression testsuite errors with rv32gcv_zvl512b

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
See also:
rv32_zvl128b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112754
rv32_zvl256b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112755
rv32_zvl512b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112756
rv32_zvl1024b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112757

[Bug target/112754] RISC-V regression testsuite errors with rv32gcv_zvl128b

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
See also:
rv32_zvl128b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112754
rv32_zvl256b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112755
rv32_zvl512b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112756
rv32_zvl1024b: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112757

[Bug target/112757] New: RISC-V regression testsuite errors with rv32gcv_zvl1024b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112757
   Summary: RISC-V regression testsuite errors with
rv32gcv_zvl1024b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56713
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56713=edit
rv32gcv_zvl1024b testsuite failures 2023-11-27

Current testsuite status of rv32gcv_zvl1024b on GCC
ad3e759c172272f6f2ba66631e7e7bd03fb2b436

I've started running rv32 zvl variants 128-1024b weekly on the postcommit CI.

Artifacts for this run can be downloaded here:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7012181120

This is just a tracking issue, similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311

I've attached the current results for rv32gcv_zvl1024b with glibc v2.37 on QEMU
v8.1.2

[Bug target/112756] New: RISC-V regression testsuite errors with rv32gcv_zvl512b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112756
   Summary: RISC-V regression testsuite errors with
rv32gcv_zvl512b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56712
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56712=edit
rv32gcv_zvl512b testsuite failures 2023-11-27

Current testsuite status of rv32gcv_zvl512b on GCC
ad3e759c172272f6f2ba66631e7e7bd03fb2b436

I've started running rv32 zvl variants 128-1024b weekly on the postcommit CI.

Artifacts for this run can be downloaded here:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7012181120

This is just a tracking issue, similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311

I've attached the current results for rv32gcv_zvl512b with glibc v2.37 on QEMU
v8.1.2

[Bug target/112755] New: RISC-V regression testsuite errors with rv32gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112755
   Summary: RISC-V regression testsuite errors with
rv32gcv_zvl256b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56711
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56711=edit
rv32gcv_zvl256b testsuite failures 2023-11-27

Current testsuite status of rv32gcv_zvl256b on GCC
ad3e759c172272f6f2ba66631e7e7bd03fb2b436

I've started running rv32 zvl variants 128-1024b weekly on the postcommit CI.

Artifacts for this run can be downloaded here:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7012181120

This is just a tracking issue, similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311

I've attached the current results for rv32gcv_zvl256b with glibc v2.37 on QEMU
v8.1.2

[Bug target/112754] New: RISC-V regression testsuite errors with rv32gcv_zvl128b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112754
   Summary: RISC-V regression testsuite errors with
rv32gcv_zvl128b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56710
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56710=edit
rv32gcv_zvl128b testsuite failures 2023-11-27

Current testsuite status of rv32gcv_zvl128b on GCC
ad3e759c172272f6f2ba66631e7e7bd03fb2b436

I've started running rv32 zvl variants 128-1024b weekly on the postcommit CI.
This is my first time running these so if any of the failures look odd poke me
here or via email and I can dig into/share the logs.

Artifacts for this run can be downloaded here:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7012181120

This is just a tracking issue, similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311

I'll open separate tracking issues for zvl 256,512,1024 and link them here when
I do.

I've attached the current results for rv32gcv_zvl128b with glibc v2.37 on QEMU
v8.1.2

[Bug rtl-optimization/55757] Suboptimal interrupt prologue/epilogue for ARMv7-M (Cortex-M3)

[yann at poupet dot eu via Gcc-bugs]

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

Yann Poupet  changed:

   What|Removed |Added

 CC||yann at poupet dot eu

--- Comment #8 from Yann Poupet  ---
Hi,

I had the same issue and modified GCC so that the prologue/epilogue do not
save/restore R4-R11 if it's not required - assuming these are caller-saved
(same effect as -fcall-used-[r4...r11]), with a new function attribute. I'm not
sure if this has a chance to be accepted upstream though.

I'm using it in 2 cases:

- ISR as described above
- for the tasks launched by my own home made microkernel. Indeed, when the
kernel starts a task starting its entry function, there's no need to save any
register, it's just a waste of stack space.

Anyone still interested with a solution ?
The patch is very small, maybe 10 lines.

Cheers
Yann

[Bug tree-optimization/112752] `~a - MIN, ~c>` is not optimized to `MAX,c> - a`

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

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

--- Comment #2 from Andrew Pinski  ---
Here is a semi-reduced testcase:
```
#define byte unsigned char
#define MIN(a, b) ((a) > (b)?(b):(a))

byte hh(byte r, byte g, byte b) {
  byte c = 255 - r;
  byte m = 255 - g;
  byte y = 255 - b;
  byte tmp = MIN(m, y);
  byte k = MIN(c, tmp);
  return m - k;
}
```
Note matching this directly, the above might not fix the original testcase.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

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

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

--- Comment #14 from Eric Botcazou  ---
> I'd say that
> 
> config/i386/cygming.h:#define STACK_REALIGN_DEFAULT TARGET_SSE
> 
> is a non-working "fix".  The appropriate default would be
> -mincoming-stack-boundary=2.  MIN_STACK_BOUNDARY should already be 4, so
> that leaves PREFERRED_STACK_BOUNDARY_DEFAULT is the way to go here.

This was a minimal fix to support SSE, but Solaris was indeed more radical:

sol2.h:#undef STACK_REALIGN_DEFAULT
sol2.h:#define STACK_REALIGN_DEFAULT (TARGET_64BIT ? 0 : 1)

so we could just mimic it for Windows.

[Bug target/112753] New: [14 Regression] unrecognizable insn building glibc for s390x

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

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

Bug ID: 112753
   Summary: [14 Regression] unrecognizable insn building glibc for
s390x
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: jchrist at linux dot ibm.com
  Target Milestone: ---
Target: s390*-*-*

Created attachment 56709
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56709=edit
preprocessed source

An ICE building glibc for s390x-linux-gnu was introduced by the commit

commit 466b100e5fee808d77598e0f294654deec281150
Author: Juergen Christ 
Date:   Mon Nov 20 09:13:10 2023 +0100

s390: implement flags output

Compile the attached test with -O2.

In file included from ../sysdeps/ieee754/ldbl-64-128/strtold_l.c:58:
./strtod_l.c: In function 'round_and_return':
./strtod_l.c:356:1: error: unrecognizable insn:
(insn 252 251 253 30 (set (reg:FPRX2 187)
(subreg:FPRX2 (reg:TF 186) 0)) "./strtod_l.c":309:218 discrim 1 -1
 (nil))
during RTL pass: vregs
./strtod_l.c:356:1: internal compiler error: in extract_insn, at recog.cc:2804
0x6f8bb8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/scratch/jmyers/glibc/many14/src/gcc/gcc/rtl-error.cc:108
0x6f8bda _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/scratch/jmyers/glibc/many14/src/gcc/gcc/rtl-error.cc:116
0x6f759b extract_insn(rtx_insn*)
/scratch/jmyers/glibc/many14/src/gcc/gcc/recog.cc:2804
0xb85405 instantiate_virtual_regs_in_insn
/scratch/jmyers/glibc/many14/src/gcc/gcc/function.cc:1610
0xb85405 instantiate_virtual_regs
/scratch/jmyers/glibc/many14/src/gcc/gcc/function.cc:1993
0xb85405 execute
/scratch/jmyers/glibc/many14/src/gcc/gcc/function.cc:2040
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/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug tree-optimization/112752] `~a - MIN, ~c>` is not optimized to `MAX,c> - a`

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

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

--- Comment #1 from Andrew Pinski  ---
I made a small mistake into what it should be optimized to:
The MIN should be MAX (oops):
that is:
tmp = MAX(r, g);
k = MAX(b, tmp);

[Bug libstdc++/112607] : _Normalize does not consider char_type for the basic_string_view case

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Fixed for 13.3 as well, thanks for the report.

[Bug tree-optimization/112752] New: `~a - MIN, ~c>` is not optimized to `MAX,c> - a`

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

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

Bug ID: 112752
   Summary: `~a - MIN, ~c>` is not optimized to
`MAX,c> - a`
   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
CC: evstupac at gmail dot com, kirill.yukhin at intel dot com,
pinskia at gcc dot gnu.org, rguenth at gcc dot gnu.org,
unassigned at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

+++ This bug was initially created as a clone of Bug #52252 +++

This is an example of byte conversion from RGB (Red Green Blue) to CMYK (Cyan
Magenta Yellow blacK):
```
#define byte unsigned char
#define MIN(a, b) ((a) > (b)?(b):(a))

void convert_image(byte *in, byte *out, int size) {
int i;
for(i = 0; i < size; i++) {
byte r = in[0];
byte g = in[1];
byte b = in[2];
byte c, m, y, k, tmp;
c = 255 - r;
m = 255 - g;
y = 255 - b;
tmp = MIN(m, y);
k = MIN(c, tmp);
out[0] = c - k;
out[1] = m - k;
out[2] = y - k;
out[3] = k;
in += 3;
out += 4;
}
}
```

For the scalar (and vectorized versions) we should get instead:
```
#define byte unsigned char
#define MIN(a, b) ((a) > (b)?(b):(a))
#define MAX(a, b) ((a) < (b)?(b):(a))

void convert_image_1(byte *in, byte *out, int size) {
int i;
for(i = 0; i < size; i++) {
byte r = in[0];
byte g = in[1];
byte b = in[2];
byte c, m, y, k, tmp;
tmp = MIN(r, g);
k = MIN(b, tmp);
out[0] = k - r;
out[1] = k - g;
out[2] = k - b;
out[3] = 255 - k;
in += 3;
out += 4;
}
}
```

See bug 52252 comment #10, 11, and 12 also.

[Bug libstdc++/112607] : _Normalize does not consider char_type for the basic_string_view case

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

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

commit r13-8105-gc7c92d61d32f6fd7746e2844f68d1936e2b6f6f6
Author: Jonathan Wakely 
Date:   Sat Nov 18 20:56:35 2023 +

libstdc++: Check string value_type in std::make_format_args [PR112607]

libstdc++-v3/ChangeLog:

PR libstdc++/112607
* include/std/format (basic_format_arg::_S_to_arg_type): Check
value_type for basic_string_view and basic_string
specializations.
* testsuite/std/format/arguments/112607.cc: New test.

(cherry picked from commit 279e407a06cc676d8e6e0bb5755b0a804e05377c)

[Bug tree-optimization/52252] An opportunity for x86 gcc vectorizer (gain up to 3 times)

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

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

--- Comment #12 from Andrew Pinski  ---
(In reply to rguent...@suse.de from comment #11)
> We're lacking a way to say one of the bit_not should be single-used,
> one multi-use would be OK and a fair trade-off - not sure if that
> would be enough here, of course.  That would mena changing to
> a condition with single_use ().

That does not fix it though. Because in this case we have:
  c_19 = ~r_16;
  m_20 = ~g_17;
  y_21 = ~b_18;
  tmp_22 = MIN_EXPR ;
  k_23 = MIN_EXPR ;
  _1 = c_19 - k_23;
  _3 = m_20 - k_23;
  _5 = y_21 - k_23;
  .. = k_23;

So both bit_not are used more than once.

so we have `~a - MIN, ~c>` which is the same as `MAX,c> -
a`.

Let me file this as a seperate bug to continue the discussion there.

[Bug middle-end/109849] suboptimal code for vector walking loop

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

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

--- Comment #31 from Jonathan Wakely  ---
Bisection points to r14-5831-gaae723d360ca26cd9fd0b039fb0a616bd0eae363 for that
remaining FAIL as well (and it isn't fixed by the new patch).

It introduced a new warning which wasn't present before:

/tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:437:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing between 2 and 9223372036854775806 bytes into a region of size 0
overflows the destination [-Wstringop-overflow=]

[Bug target/111170] [13/14 regression] Malformed manifest does not allow to run gcc on Windows XP (Accessing a corrupted shared library) since r13-6552-gd11e088210a551

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #13 from Eric Botcazou  ---
Thanks for the fix.  Now it needs to be backported onto the 13 branch.

[Bug c++/53220] [4.7/4.8 Regression] g++ mis-compiles compound literals

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

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

--- Comment #23 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:305a2686c99bf9b57490419f25c79f6fb3ae0feb

commit r14-5941-g305a2686c99bf9b57490419f25c79f6fb3ae0feb
Author: Jason Merrill 
Date:   Tue Nov 28 13:54:47 2023 -0500

c++: prvalue array decay [PR94264]

My change for PR53220 made array to pointer decay for prvalue arrays
ill-formed to catch well-defined C code that produces a dangling pointer in
C++ due to the shorter lifetime of compound literals.  This wasn't really
correct, but wasn't a problem until C++17 added prvalue arrays, at which
point it started rejecting valid C++ code.

I wanted to make sure that we still diagnose the problematic code;
-Wdangling-pointer covers the array-lit.c case, but I needed to extend
-Wreturn-local-addr to handle the return case.

PR c++/94264
PR c++/53220

gcc/c/ChangeLog:

* c-typeck.cc (array_to_pointer_conversion): Adjust -Wc++-compat
diagnostic.

gcc/cp/ChangeLog:

* call.cc (convert_like_internal): Remove obsolete comment.
* typeck.cc (decay_conversion): Allow array prvalue.
(maybe_warn_about_returning_address_of_local): Check
for returning pointer to temporary.

gcc/testsuite/ChangeLog:

* c-c++-common/array-lit.c: Adjust.
* g++.dg/cpp1z/array-prvalue1.C: New test.
* g++.dg/ext/complit17.C: New test.

[Bug c++/94264] Array-to-pointer conversion not performed on array prvalues

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

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

--- Comment #8 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:305a2686c99bf9b57490419f25c79f6fb3ae0feb

commit r14-5941-g305a2686c99bf9b57490419f25c79f6fb3ae0feb
Author: Jason Merrill 
Date:   Tue Nov 28 13:54:47 2023 -0500

c++: prvalue array decay [PR94264]

My change for PR53220 made array to pointer decay for prvalue arrays
ill-formed to catch well-defined C code that produces a dangling pointer in
C++ due to the shorter lifetime of compound literals.  This wasn't really
correct, but wasn't a problem until C++17 added prvalue arrays, at which
point it started rejecting valid C++ code.

I wanted to make sure that we still diagnose the problematic code;
-Wdangling-pointer covers the array-lit.c case, but I needed to extend
-Wreturn-local-addr to handle the return case.

PR c++/94264
PR c++/53220

gcc/c/ChangeLog:

* c-typeck.cc (array_to_pointer_conversion): Adjust -Wc++-compat
diagnostic.

gcc/cp/ChangeLog:

* call.cc (convert_like_internal): Remove obsolete comment.
* typeck.cc (decay_conversion): Allow array prvalue.
(maybe_warn_about_returning_address_of_local): Check
for returning pointer to temporary.

gcc/testsuite/ChangeLog:

* c-c++-common/array-lit.c: Adjust.
* g++.dg/cpp1z/array-prvalue1.C: New test.
* g++.dg/ext/complit17.C: New test.

[Bug target/112751] [14 regression] gcc.target/powerpc/pcrel-sibcall-1.c fails after r14-5628-g53ba8d669550d3

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

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

--- Comment #1 from Andrew Pinski  ---
This is just a testsuite issue. The functions are currently marked as noinline.
 You can either add -fno-ipa-vrp or mark them with noipa instead. I am not sure
if noipa here is right due to having some ipa happening due to localization.

[Bug target/112751] New: [14 regression] gcc.target/powerpc/pcrel-sibcall-1.c fails after r14-5628-g53ba8d669550d3

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

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

Bug ID: 112751
   Summary: [14 regression] gcc.target/powerpc/pcrel-sibcall-1.c
fails after r14-5628-g53ba8d669550d3
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:53ba8d669550d3a1f809048428b97ca607f95cf5, r14-5628-g53ba8d669550d3
make  -k check-gcc
RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/pcrel-sibcall-1.c"
FAIL: gcc.target/powerpc/pcrel-sibcall-1.c scan-assembler \\mb x@notoc\\M
FAIL: gcc.target/powerpc/pcrel-sibcall-1.c scan-assembler \\mbl y\\M
FAIL: gcc.target/powerpc/pcrel-sibcall-1.c scan-assembler \\mb xx@notoc\\M
# of expected passes2
# of unexpected failures3


commit 53ba8d669550d3a1f809048428b97ca607f95cf5 (HEAD)
Author: Jan Hubicka 
Date:   Mon Nov 20 19:35:53 2023 +0100

inter-procedural value range propagation

[Bug c++/102419] [11/12/13/14 Regression][concepts] return-type-requirement of "Y" does not check that T::type actually exists

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||novulae at hotmail dot com

--- Comment #10 from Patrick Palka  ---
*** Bug 112749 has been marked as a duplicate of this bug. ***

[Bug c++/112749] GCC accepts invalid code in concepts (requires clause incorrectly satisfied)

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
Thanks for the bug report, I think this is pretty much a dup of PR102419.

GCC is behaving correctly here: the normal form of the constraint C1> is
just 'true (with empty parameter mapping)' which is independent of the template
parameter, so the constraint is trivially satisfied for any choice of T.  To
get the behavior you desire, define C1 in a way that depends on its template
parameter e.g.

template concept C1 = requires { typename T; };

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

[Bug target/112606] [14 Regression] powerpc64le-linux-gnu: 'FAIL: gcc.target/powerpc/p8vector-fp.c scan-assembler xsnabsdp'

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #3 from seurer at gcc dot gnu.org ---
These tests also fail starting with g:9e9279fadbd1c673c875b9d20261d2de0473f63f,
r14-5542-g9e9279fadbd1c6

FAIL: gcc.target/powerpc/float128-hw5.c scan-assembler-not \\mxscpsgnqp\\M
FAIL: gcc.target/powerpc/float128-hw5.c scan-assembler-times \\mxsnabsqp\\M 1
FAIL: gcc.target/powerpc/float128-hw7.c scan-assembler-not \\mxscpsgnqp\\M
FAIL: gcc.target/powerpc/float128-hw7.c scan-assembler-times \\mxsnabsqp\\M 1

[Bug c++/112744] Nested name specifier wrongly produces ambiguity in accessing static field

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug middle-end/112750] New: wrong code with _BitInt(256) and above and __builtin_sub_overflow_p() at -O0

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112750
   Summary: wrong code with _BitInt(256) and above and
__builtin_sub_overflow_p() at -O0
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Output:
$ x86_64-pc-linux-gnu-gcc testcase.c
$ ./a.out 
Aborted

__builtin_sub_overflow_p() should indicate overflow, since 0xC00C598D can't fit
into int.

$ 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-5935-20231128165834-gf45d5e30bd9-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/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-5935-20231128165834-gf45d5e30bd9-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231128 (experimental) (GCC)

[Bug c++/112744] Nested name specifier wrongly produces ambiguity in accessing static field

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed, I think.  Since a is static, there is only one copy.  So it should
not matter that A is an ambiguous base of D (which it is).  See [class]/note-3.

For the error line, in finish_class_member_access_expr scope will be A, so we
do
 3496   /* Find the base of OBJECT_TYPE corresponding to SCOPE.  */
 3497   access_path = lookup_base (object_type, scope, ba_check,
 3498  NULL, complain);
where object_type=D, scope=A.  But the ba_check means we give an error.

We don't know at this point that name refers to a static data member.  But we
can look it up, and maybe use ba_any.

Not a regression.

[Bug c++/112749] New: GCC accepts invalid code in concepts (requires clause incorrectly satisfied)

[novulae at hotmail dot com via Gcc-bugs]

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

Bug ID: 112749
   Summary: GCC accepts invalid code in concepts (requires clause
incorrectly satisfied)
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: novulae at hotmail dot com
  Target Milestone: ---

The below example is ill-formed - the requires clause should not be satisfied
due to the failure to instantiate W1, but GCC accepts the code
nonetheless.

Clang rejects the code.

$ cat gcc-bug.cpp
template concept C1 = true;

template using W1 = decltype(nonexistent(0));

template
requires C1>
void func(T);

void test() {
  func(0);
}

$ g++ -c -std=c++20 gcc-bug.cpp

$ clang++ -c -std=c++20 gcc-bug.cpp
gcc-bug.cpp:10:3: error: no matching function for call to 'func'
   10 |   func(0);
  |   ^~~~
gcc-bug.cpp:7:6: note: candidate template ignored: constraints not satisfied
[with T = int]
7 | void func(T);
  |  ^
gcc-bug.cpp:3:39: note: because substituted constraint expression is
ill-formed: use of undeclared identifier 'nonexistent'
3 | template using W1 = decltype(nonexistent(0));
  |   ^
1 error generated.

[Bug middle-end/112748] memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined

[tavianator at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Tavian Barnes  ---
(In reply to Andrew Pinski from comment #1)
> Does -fsanitize=address remove it?

Yes, it's still removed with -fsanitize=address.

While ASAN is necessary to check that the memory is really allocated, UBSAN
should at least check that ptr is not NULL.  So it shouldn't be removed in
either case.

[Bug middle-end/112748] memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined

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

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

--- Comment #1 from Andrew Pinski  ---
Does -fsanitize=address remove it?

[Bug c++/94264] Array-to-pointer conversion not performed on array prvalues

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
This is due to my PR53220 change to discourage use of compound-literals in ways
that produce a dangling pointer when the C++ compiler treats them as prvalues,
unlike C where they have variable lifetime.

I think the change was always wrong, but wasn't really a problem until we added
array prvalues in C++17.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220
[Bug 53220] [4.7/4.8 Regression] g++ mis-compiles compound literals

[Bug c/112748] New: memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined

[tavianator at gmail dot com via Gcc-bugs]

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

Bug ID: 112748
   Summary: memmove(ptr, ptr, n) call optimized out even at -O0
with -fsanitize=undefined
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tavianator at gmail dot com
  Target Milestone: ---

This is counter-productive, as I wrote the memmove() specifically to get the
sanitizers to check that ptr really points to a big enough allocation.

$ cat foo.c
typedef __SIZE_TYPE__ size_t;
void *memmove(void *dest, void *src, size_t n);

void foo(void *ptr, size_t n) {
memmove(ptr, ptr, n);
}
$ gcc -O0 -fsanitize=undefined -S foo.c
$ cat foo.s
.file   "foo.c"
.text
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movq%rdi, -8(%rbp)
movq%rsi, -16(%rbp)
nop
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 13.2.1 20230801"
.section.note.GNU-stack,"",@progbits

[Bug tree-optimization/112738] [14 Regression] forwprop4 introduces invalid wide signed Boolean values

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/112738] [14 Regression] forwprop4 introduces invalid wide signed Boolean values

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

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

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

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

commit r14-5938-g68ffaf839883253e0f288862ff20b8005c92df4e
Author: Andrew Pinski 
Date:   Mon Nov 27 16:41:25 2023 -0800

MATCH: Fix invalid signed boolean type usage

This fixes the incorrect assumption that was done in
r14-3721-ge6bcf839894783,
that being able to doing the negative after the conversion would be a valid
thing
but really it is not valid for boolean types.

Bootstrapped and tested on x86_64-linux-gnu.

gcc/ChangeLog:

PR tree-optimization/112738
* match.pd (`(nop_convert)-(convert)a`): Reject
when the outer type is boolean.

Signed-off-by: Andrew Pinski 

[Bug middle-end/112733] [14 Regression] ICE: Segmentation fault in wide-int.cc during GIMPLE pass: sccp

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

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

--- Comment #11 from Jakub Jelinek  ---
Created attachment 56707
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56707=edit
gcc14-pr112733-2.patch

Second patch to be tested.  Turned out it is more complicated than that.
If n > m, i.e. when divisor in absolute value is larger than dividend, we want
divmod_internal_2 to know that, such that e.g. it skips the main loop and looks
at correct most significant half limb of the divisor, but the
  if (s)
for (i = 0; i < n; i++)
  b_remainder[i] = (b_dividend[i] >> s)
| (b_dividend[i+1] << (HOST_BITS_PER_HALF_WIDE_INT - s));
  else
for (i = 0; i < n; i++)
  b_remainder[i] = b_dividend[i];
loops in such case already may invoke UB, because they copy stuff from
b_dividend which just isn't there, at best some random upper bits, at worst
crash.  We can't copy more than there is in the array and need to tell the
caller how much we've initialized, so that wi_pack can take it into account.

While looking into this, I've noticed that I've allocated in case of XALLOCAVEC
multiplication and division/remainder calculations twice or 4 times as much
as really needed, so this patch fixes that too.

[Bug middle-end/112733] [14 Regression] ICE: Segmentation fault in wide-int.cc during GIMPLE pass: sccp

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

First patch to be tested.

[Bug middle-end/112560] [14 Regression] ICE in try_combine on pr112494.c

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Status|NEW |ASSIGNED

--- Comment #3 from Uroš Bizjak  ---
Created attachment 56705
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56705=edit
Proposed patch

The code assumes that cc_use_loc represents a comparison operator. Skip the
modification of CC-using operation if this is not the case.

[Bug c++/103183] [11/12/13/14 Regression] ind[arr] produces an lvalue when arr is an array xvalue

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
Summary|ind[arr] produces an lvalue |[11/12/13/14 Regression]
   |when arr is an array xvalue |ind[arr] produces an lvalue
   ||when arr is an array xvalue
   Target Milestone|--- |11.5

--- Comment #4 from Patrick Palka  ---
Like PR103185, this one also started with r10-3793-g1a37b6d9a7e57c

[Bug pch/64117] warning control #pragmas in precompiled headers are not obeyed for template code

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||piannetta at kalrayinc dot com

--- Comment #9 from Lewis Hyatt  ---
*** Bug 112747 has been marked as a duplicate of this bug. ***

[Bug pch/112747] #pragma GCC diagnostic ignored "-Wstringop-overflow" has no effect in pre-compiled headers.

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

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

Lewis Hyatt  changed:

   What|Removed |Added

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

--- Comment #1 from Lewis Hyatt  ---
Thanks, it is PR 64117; the patch waiting for review there will fix it.

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

[Bug c++/103185] [11/12/13/14 Regression] ind[arr] is rejected when arr is an array prvalue

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |11.5

[Bug c++/103185] [11/12/13/14 Regression] ind[arr] is rejected when arr is an array prvalue

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|ind[arr] is rejected when   |[11/12/13/14 Regression]
   |arr is an array prvalue |ind[arr] is rejected when
   ||arr is an array prvalue
 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Started to be rejected in C++17 mode since r10-3793-g1a37b6d9a7e57c:

using intarr = int[];
using type = decltype(0[intarr{0}]); // { dg-bogus "taking address of temporary
array" }

[Bug ada/111909] Filename case sensitivity defaulted wrongly on macOS

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Marc Poulhi?s :

https://gcc.gnu.org/g:396db92d3aa7412dd7133563fecbc6237fa81c02

commit r14-5936-g396db92d3aa7412dd7133563fecbc6237fa81c02
Author: Simon Wright 
Date:   Tue Nov 28 14:56:36 2023 +0100

Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at
runtime

In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
assumption for __APPLE__ is that file names are case-insensitive
unless __arm__ or __arm64__ are defined, in which case file names are
declared case-sensitive.

The associated comment is
  "By default, we suppose filesystems aren't case sensitive on
  Windows and Darwin (but they are on arm-darwin)."

This means that on aarch64-apple-darwin, file names are treated as
case-sensitive, which is not the default case.

The true default position is that macOS file systems are
case-insensitive, iOS file systems are case-sensitive.

Apple provide a header file  which permits a
compile-time check for the compiler target (e.g. OSX vs IOS); if
TARGET_OS_IOS is defined as 1, this is a build for iOS.

2023-11-22  Simon Wright  

gcc/ada/

PR ada/111909
* adaint.c
(__gnat_get_file_names_case_sensitive): Split out the __APPLE__
check and remove the checks for __arm__, __arm64__. For Apple,
file names are by default case-insensitive unless TARGET_OS_IOS is
set.

Signed-off-by: Simon Wright 

[Bug tree-optimization/112746] Missed optimization for exact division with multi-use addition chain

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|Missed optimization for |Missed optimization for
   |redundancy computation  |exact division with
   |elimination (fre1(tree) for |multi-use addition chain
   |global variable)|
   Last reconfirmed||2023-11-28

--- Comment #1 from Richard Biener  ---
The issue with test2 is that with value-numbering we have

(n.3_1 * 2 + n.3_1) / n.3_1

and that does not simplify.  That is, we do not simplify 2 * n + n to
3 * n as in general that wouldn't be profitable if 2 * n is live after
the use is elided (and it is live since it's stored to 'b').

Which means we ask for (n.3_1 * 2 + n.3_1) / n.3_1 which we currently
cannot simplify to a constant.  Handling cases like this in match.pd
feels wrong.

Note that with -fwrapv the optimization wouldn't be valid.

Other passes face the same issue, 'b' keeps n*2 live so an add
looks cheaper than to compute n*3 for the division.  We're not
anticipating the division here.

But:

  _3 = n.3_1 + _2;
  _4 = _3 / n.3_1;

could be simplified to

  _5 = _2 / n.3_1;
  _4 = _5 + 1;

if we know _2 is a multiple of n.3_1 which then could be simplified as well.

Note that all passes doing analyses on addition chains also stop at the
multi-use, so we'd need to improve at that point somehow.

[Bug pch/112747] New: #pragma GCC diagnostic ignored "-Wstringop-overflow" has no effect in pre-compiled headers.

[piannetta at kalrayinc dot com via Gcc-bugs]

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

Bug ID: 112747
   Summary: #pragma GCC diagnostic ignored "-Wstringop-overflow"
has no effect in pre-compiled headers.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piannetta at kalrayinc dot com
  Target Milestone: ---

==> t.c <==
#include "t.h"

extern char a[10];

int g ()
{
  return f(a, 11, 1);
}

==> t.h <==
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-overflow"
static char f (char *a, int idx, char v) { return a[idx] = v; }
#pragma GCC diagnostic pop

=

$ gcc t.c -O2 -c
$ gcc t.h -O2
$ gcc t.c -O2
In function 'f',
inlined from 'g' at t.c:8:10:
t.h:3:58: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
t.c: In function 'g':
t.c:4:13: note: at offset 11 into destination object 'a' of size 10

=

-Wstringop-overflow is not ignored as it ought to be when a pre-compiled header
exists. This cause the test
gcc/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/minimal.cc
from libstdc++v3 to fail.

I can reproduce the bug on gcc12, gcc13, gcc14 and trunk.

[Bug target/112280] [14 regression] ICE building libgcrypt-1.10.2 on s390 (during GIMPLE pass: ccp)

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

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

--- Comment #8 from Sam James  ---
I suspect I've just hit this when trying to build pixman on s390x too.

[Bug tree-optimization/112746] New: Missed optimization for redundancy computation elimination (fre1(tree) for global variable)

[652023330028 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 112746
   Summary: Missed optimization for redundancy computation
elimination (fre1(tree) for global variable)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we noticed that maybe there is a missed optimization for redundancy
computation elimination.

When b is a local variable, the computation of m optimizes to 3 as expected.
When b appears as a global variable, it misses this optimization.

https://godbolt.org/z/j3cKsrKb6

int n,m;
int b;
void test(int b){
b=n+n;
m=(n+b)/(n);
}
void test2(){
b=n+n;
m=(n+b)/(n);
}

But GCC -O3 -fwrapv or GCC -O3:
test(int):
mov DWORD PTR m[rip], 3
ret
test2():
mov ecx, DWORD PTR n[rip]
lea eax, [rcx+rcx]
mov DWORD PTR b[rip], eax
add eax, ecx
cdq
idivecx
mov DWORD PTR m[rip], eax
ret

Expected code (Clang):
test2():  # @test2()
mov eax, dword ptr [rip + n]
add eax, eax
mov dword ptr [rip + b], eax
mov dword ptr [rip + m], 3
ret

We see a difference in fre1(tree) for these two functions, which might help
with this issue:
void test (int b)
{
  int n.0_1;
  int _3;
  int _5;

   :
  # DEBUG BEGIN_STMT
  n.0_1 = n;
  b_7 = n.0_1 * 2;
  # DEBUG b => b_7
  # DEBUG BEGIN_STMT
  _3 = n.0_1 * 3;
  _5 = 3;
  m = 3;
  return;

}

void test2 ()
{
  int n.3_1;
  int _2;
  int _5;
  int _7;

   :
  # DEBUG BEGIN_STMT
  n.3_1 = n;
  _2 = n.3_1 * 2;
  b = _2;
  # DEBUG BEGIN_STMT
  _5 = n.3_1 + _2;
  _7 = _5 / n.3_1;
  m = _7;
  return;

}


Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug middle-end/112733] [14 Regression] ICE: Segmentation fault in wide-int.cc during GIMPLE pass: sccp

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

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

--- Comment #9 from Jakub Jelinek  ---
Actually, maybe better variant of the first fix in the above comment would be:
--- gcc/wide-int.cc.jj  2023-11-28 16:56:50.0 +0100
+++ gcc/wide-int.cc 2023-11-28 16:58:02.268776755 +0100
@@ -1985,6 +1985,8 @@ wi::divmod_internal (HOST_WIDE_INT *quot

   if (remainder)
 {
+  if (n > dividend_blocks_needed)
+   n = dividend_blocks_needed;
   *remainder_len = wi_pack (remainder, b_remainder, n, dividend_prec);
   /* The remainder is always the same sign as the dividend.  */
   if (dividend_neg)
where the check which is useless for multiplication and quotient is done only
in the problematic spot - remainder.

[Bug target/112494] ICE in ix86_cc_mode, at config/i386/i386.cc:16477

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #10 from Uroš Bizjak  ---
Fixed for 14.0.

[Bug middle-end/112560] [14 Regression] ICE in try_combine on pr112494.c

[ubizjak at gmail dot com via Gcc-bugs]

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

Bug 112494 Summary: ICE in ix86_cc_mode, at config/i386/i386.cc:16477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494

   What|Removed |Added

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

[Bug lto/112732] during IPA pass: *free_lang_data ICE: 'verify_type' failed: type variant with 'TYPE_ALIAS_SET_KNOWN_P' with -Os -Wstrict-aliasing=2 -flto

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed on trunk.

[Bug c/101057] [gimplefe] GIMPLE frontend issues

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

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

Bug 112741 Summary: ICE: in gimplify_var_or_parm_decl, at gimplify.cc:3261
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112741

   What|Removed |Added

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

[Bug sanitizer/112741] ICE: in gimplify_var_or_parm_decl, at gimplify.cc:3261

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed on trunk.

[Bug sanitizer/112741] ICE: in gimplify_var_or_parm_decl, at gimplify.cc:3261

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

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

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

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

commit r14-5935-gf45d5e30bd98ea1d8dc29841a06b2cfa5662deb5
Author: Richard Biener 
Date:   Tue Nov 28 12:49:35 2023 +0100

middle-end/112741 - ICE with gimple FE and later regimplification

The GIMPLE frontend, when bypassing gimplification, doesn't set
DECL_SEEN_IN_BIND_EXPR_P given there are no such things in GIMPLE.
But it probably should set the flag anyway to avoid later ICEs
when regimplifying.

PR middle-end/112741
gcc/c/
* gimple-parser.cc (c_parser_parse_gimple_body): Also
set DECL_SEEN_IN_BIND_EXPR_Pfor locals.

gcc/testsuite/
* gcc.dg/ubsan/pr112741.c: New testcase.

[Bug lto/112732] during IPA pass: *free_lang_data ICE: 'verify_type' failed: type variant with 'TYPE_ALIAS_SET_KNOWN_P' with -Os -Wstrict-aliasing=2 -flto

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

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

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

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

commit r14-5934-gf26d68d5d128c86faaceeb81b1e8f22254ad53df
Author: Richard Biener 
Date:   Tue Nov 28 12:36:21 2023 +0100

middle-end/112732 - stray TYPE_ALIAS_SET in type variant

The following fixes a stray TYPE_ALIAS_SET in a type variant built
by build_opaque_vector_type which is diagnosed by type checking
enabled with -flto.

PR middle-end/112732
* tree.cc (build_opaque_vector_type): Reset TYPE_ALIAS_SET
of the newly built type.

[Bug target/112494] ICE in ix86_cc_mode, at config/i386/i386.cc:16477

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:99db2ce2419245e40808a9fad45113315496a907

commit r14-5933-g99db2ce2419245e40808a9fad45113315496a907
Author: Uros Bizjak 
Date:   Tue Nov 28 16:56:29 2023 +0100

i386: Improve cmpstrnqi_1 insn pattern [PR112494]

REPZ CMPSB instruction does not update FLAGS register when %ecx register
equals zero.  Improve cmpstrnqi_1 insn pattern to set FLAGS_REG to its
previous value instead of (const_int 0) when operand 2 equals zero.

PR target/112494

gcc/ChangeLog:

* config/i386/i386.md (cmpstrnqi_1): Set FLAGS_REG to its previous
value when operand 2 equals zero.
(*cmpstrnqi_1): Ditto.
(*cmpstrnqi_1 peephole2): Ditto.

[Bug middle-end/112733] [14 Regression] ICE: Segmentation fault in wide-int.cc during GIMPLE pass: sccp

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

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

--- Comment #8 from Jakub Jelinek  ---
As for the actual crash, I have again multiple possible fixes:
--- gcc/wide-int.cc.jj  2023-10-16 14:24:46.360204472 +0200
+++ gcc/wide-int.cc 2023-11-28 16:33:35.737394223 +0100
@@ -1297,6 +1297,8 @@ wi_pack (HOST_WIDE_INT *result,
   unsigned int j = 0;
   unsigned int blocks_needed = BLOCKS_NEEDED (precision);

+  if (in_len > blocks_needed * 2)
+in_len = blocks_needed * 2;
   while (i + 1 < in_len)
 {
   result[j++] = ((unsigned HOST_WIDE_INT) input[i]
Or another option is ensure that in_len is never larger than blocks_needed * 2.
The problem with the wide-int.cc wi_pack calls for remainder is that
the in_len argument in that case is n (which is:
  n = divisor_blocks_needed;
  while (n > 1 && b_divisor[n - 1] == 0)
n--;
i.e. at most 2 * BLOCKS_NEEDED (divisor_prec), but the last
argument is dividend_prec rather than divisor_prec.
In reality, I think the remainder is bound by both minimum precision
of dividend and divisor, because it can't be in absolute value larger
than the divisor and can't be in absolute value larger than dividend.
--- gcc/wide-int.h.jj   2023-10-14 11:08:20.790471175 +0200
+++ gcc/wide-int.h  2023-11-28 16:44:26.576265870 +0100
@@ -3179,6 +3179,10 @@ wi::div_floor (const T1 , const T2 ,
   else
est_len = xi.len + 1;
   quotient_val = quotient.write_val (est_len);
+  if (sgn == UNSIGNED && yi.val[yi.len - 1] < 0)
+   est_len = CEIL (precision, HOST_BITS_PER_WIDE_INT) + 1;
+  else
+   est_len = yi.len + 1;
   remainder_val = remainder.write_val (est_len);
 }
   quotient.set_len (divmod_internal (quotient_val,
@@ -3231,6 +3235,10 @@ wi::div_ceil (const T1 , const T2 ,
   else
est_len = xi.len + 1;
   quotient_val = quotient.write_val (est_len);
+  if (sgn == UNSIGNED && yi.val[yi.len - 1] < 0)
+   est_len = CEIL (precision, HOST_BITS_PER_WIDE_INT) + 1;
+  else
+   est_len = yi.len + 1;
   remainder_val = remainder.write_val (est_len);
 }
   quotient.set_len (divmod_internal (quotient_val,
@@ -3274,6 +3282,10 @@ wi::div_round (const T1 , const T2 ,
   else
est_len = xi.len + 1;
   quotient_val = quotient.write_val (est_len);
+  if (sgn == UNSIGNED && yi.val[yi.len - 1] < 0)
+   est_len = CEIL (precision, HOST_BITS_PER_WIDE_INT) + 1;
+  else
+   est_len = yi.len + 1;
   remainder_val = remainder.write_val (est_len);
 }
   quotient.set_len (divmod_internal (quotient_val,
@@ -3327,6 +3339,10 @@ wi::divmod_trunc (const T1 , const T2
   else
est_len = xi.len + 1;
   quotient_val = quotient.write_val (est_len);
+  if (sgn == UNSIGNED && yi.val[yi.len - 1] < 0)
+   est_len = CEIL (precision, HOST_BITS_PER_WIDE_INT) + 1;
+  else
+   est_len = yi.len + 1;
   remainder_val = remainder.write_val (est_len);
 }
   quotient.set_len (divmod_internal (quotient_val,
@@ -3375,10 +3391,10 @@ wi::mod_trunc (const T1 , const T2 ,
   unsigned int remainder_len;
   if (remainder.needs_write_val_arg)
 remainder_val = remainder.write_val ((sgn == UNSIGNED
- && xi.val[xi.len - 1] < 0)
+ && yi.val[yi.len - 1] < 0)
 ? CEIL (precision,
 HOST_BITS_PER_WIDE_INT) + 1
-: xi.len + 1);
+: yi.len + 1);
   divmod_internal (0, _len, remainder_val,
   xi.val, xi.len, precision,
   yi.val, yi.len, yi.precision, sgn, overflow);
@@ -3427,6 +3443,10 @@ wi::mod_floor (const T1 , const T2 ,
   else
est_len = xi.len + 1;
   quotient_val = quotient.write_val (est_len);
+  if (sgn == UNSIGNED && yi.val[yi.len - 1] < 0)
+   est_len = CEIL (precision, HOST_BITS_PER_WIDE_INT) + 1;
+  else
+   est_len = yi.len + 1;
   remainder_val = remainder.write_val (est_len);
 }
   quotient.set_len (divmod_internal (quotient_val,
@@ -3473,6 +3493,10 @@ wi::mod_ceil (const T1 , const T2 ,
   else
est_len = xi.len + 1;
   quotient_val = quotient.write_val (est_len);
+  if (sgn == UNSIGNED && yi.val[yi.len - 1] < 0)
+   est_len = CEIL (precision, HOST_BITS_PER_WIDE_INT) + 1;
+  else
+   est_len = yi.len + 1;
   remainder_val = remainder.write_val (est_len);
 }
   quotient.set_len (divmod_internal (quotient_val,
@@ -3509,6 +3533,10 @@ wi::mod_round (const T1 , const T2 ,
   else
est_len = xi.len + 1;
   quotient_val = quotient.write_val (est_len);
+  if (sgn == UNSIGNED && yi.val[yi.len - 1] < 0)
+   est_len = CEIL (precision, HOST_BITS_PER_WIDE_INT) + 1;
+  else
+   est_len = yi.len + 1;
   remainder_val = remainder.write_val (est_len);
 }
   quotient.set_len (divmod_internal 

[Bug target/109253] libbpf: failed to find BTF info for global/extern symbol '__divdi3'

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

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

--- Comment #4 from Jose E. Marchesi  ---
Fixed by the commit above.

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

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

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

--- Comment #5 from Segher Boessenkool  ---
The insn that it fails on is the result from a split using *tls_ld .

[Bug middle-end/111754] [14 Regression] ICE: in decompose, at rtl.h:2313 at -O

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

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

--- Comment #15 from prathamesh3492 at gcc dot gnu.org ---
Sorry for the regression, and thanks for the prompt fix!

[Bug fortran/37336] [F03] Finish derived-type finalization

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

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

Bug 110415 Summary: (Re)allocation on assignment to allocatable polymorphic 
variable from allocatable polymorphic function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110415

   What|Removed |Added

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

[Bug fortran/110415] (Re)allocation on assignment to allocatable polymorphic variable from allocatable polymorphic function result

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

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

Andrew Jenner  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||andrewjenner at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #5 from Andrew Jenner  ---
Fixed on mainline and OG13. I will apply the commit to GCC 13 after the grace
period.

[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu

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

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

--- Comment #4 from Segher Boessenkool  ---
It needs   -O2 -fPIC -fno-exceptions   to fail.

[Bug middle-end/109849] suboptimal code for vector walking loop

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

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

--- Comment #30 from Jonathan Wakely  ---
So far the only FAIL is still see is:

FAIL: 23_containers/vector/types/1.cc  -std=gnu++98 (test for excess errors)

I'm not sure if this is caused by your patch or one of Honza's. The test only
fails with GLIBCXX_TESTSUITE_STDS=98 defined.

[Bug fortran/110415] (Re)allocation on assignment to allocatable polymorphic variable from allocatable polymorphic function result

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Andrew Jenner :

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

commit r14-5931-gb247e917ff13328298c1eecf8563b12edd7ade04
Author: Andrew Jenner 
Date:   Tue Nov 28 15:27:05 2023 +

Fortran: fix reallocation on assignment of polymorphic variables [PR110415]

This patch fixes two bugs related to polymorphic class assignment in the
Fortran front-end. One (described in PR110415) is an issue with the malloc
and realloc calls using the size from the old vptr rather than the new one.
The other is caused by the return value from the realloc call being
ignored.
Testcases are added for these issues.

2023-11-28  Andrew Jenner  

gcc/fortran/
PR fortran/110415
* trans-expr.cc (trans_class_vptr_len_assignment): Add
from_vptrp parameter. Populate it. Don't check for DECL_P
when deciding whether to create temporary.
(trans_class_pointer_fcn, gfc_trans_pointer_assignment): Add
NULL argument to trans_class_vptr_len_assignment calls.
(trans_class_assignment): Get rhs_vptr from
trans_class_vptr_len_assignment and use it for determining size
for allocation/reallocation. Use return value from realloc.

gcc/testsuite/
PR fortran/110415
* gfortran.dg/pr110415.f90: New test.
* gfortran.dg/asan/pr110415-2.f90: New test.
* gfortran.dg/asan/pr110415-3.f90: New test.

Co-Authored-By: Tobias Burnus  

[Bug target/109253] libbpf: failed to find BTF info for global/extern symbol '__divdi3'

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Jose E. Marchesi :

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

commit r14-5930-gf31a019d1161ec78846473da743aedf49cca8c27
Author: Jose E. Marchesi 
Date:   Fri Nov 24 06:30:28 2023 +0100

Emit funcall external declarations only if actually used.

There are many places in GCC where alternative local sequences are
tried in order to determine what is the cheapest or best alternative
to use in the current target.  When any of these sequences involve a
libcall, the current implementation of emit_library_call_value_1
introduce a side-effect consisting on emitting an external declaration
for the funcall (such as __divdi3) which is thus emitted even if the
sequence that does the libcall is not retained.

This is problematic in targets such as BPF, because the kernel loader
chokes on the spurious symbol __divdi3 and makes the resulting BPF
object unloadable.  Note that BPF objects are not linked before being
loaded.

This patch changes asssemble_external_libcall to defer emitting
declarations of external libcall symbols, by saving the call tree
nodes in a temporary list pending_libcall_symbols and letting
process_pending_assembly_externals to emit them only if they have been
referenced.  Solution suggested and sketched by Richard Sandiford.

Regtested in x86_64-linux-gnu.
Tested with host x86_64-linux-gnu with target bpf-unknown-none.

gcc/ChangeLog

PR target/109253
* varasm.cc (pending_libcall_symbols): New variable.
(process_pending_assemble_externals): Process
pending_libcall_symbols.
(assemble_external_libcall): Defer emitting external libcall
symbols to process_pending_assemble_externals.

gcc/testsuite/ChangeLog

PR target/109253
* gcc.target/bpf/divmod-libcall-1.c: New test.
* gcc.target/bpf/divmod-libcall-2.c: Likewise.
* gcc.c-torture/compile/libcall-2.c: Likewise.

[Bug lto/112716] LTO optimization with struct with variable size

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #9 from Martin Uecker  ---
(In reply to Richard Biener from comment #8)
> (In reply to uecker from comment #7)
>

> > > 
> > > Note that even without LTO when you enable inlining you'd expose two
> > > different structures with two different alias-sets, possibly leading
> > > to wrong-code (look at the RTL expansion dump and check alias-sets).
> > 
> > Yes, for pre C23 this is true for all structs even without VLA.
> > But for C23 this changes.
> > 
> > The main case where the GNU extension is interesting and useful is
> > when the VLA field is at the end. So at least for this case it would
> > be nice to have a solution.
> 
> So what's the GNU extension here?  VLA inside structs are not a C thing?

ISO C does not currently allow VLAs or variably-modified types
inside structs. So all these are GNU extensions.

WG14 is thinking about allowing pointers to VLAs  inside structs.

struct foo {
  int n;
  char (*buf)[.n];
};

But this is a bit different because it would not depend on an
external value.

> I suppose if they were then C23 would make only the "abstract" types
> compatible but the concrete types (actual 'n') would only be compatible
> when 'n' is the same?

Yes, this is how it works for other variably-modified types
in C (since C99) where it is then run-time undefined behavior
if 'n' turns out not to be the same.

> 
> I think the GNU extension is incomplete, IIRC you can't have
> 
> foo (int n, struct bar { int x; int a[n]; } b) -> struct bar
> {
>   return bar;
> }
> 
> and there's no way to 'declare' bar in a way that it's usable across
> functions.

You could declare it again in another function

void xyz(int n)
{
  struct bar { int x; int a[n]; } y;
  foo(n, y);
}

and with C23 compatibility rules this would work. 

> 
> So I'm not sure assigning C23 "semantics" to this extension is very
> useful.  Your examples are awkward workarounds for an incomplete
> language extension.

In any case, we already have the extension and we should
either we make it more useful, or document its limitations, 
or deprecate it completely.

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

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

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

Rainer Orth  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #16 from Rainer Orth  ---
Fixed for GCC 14.

[Bug middle-end/112733] [14 Regression] ICE: Segmentation fault in wide-int.cc during GIMPLE pass: sccp

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
On the fold-const.cc side, we IMHO should either do:
--- gcc/fold-const.cc.jj2023-11-28 08:46:28.345803059 +0100
+++ gcc/fold-const.cc   2023-11-28 15:37:28.252327265 +0100
@@ -14563,7 +14563,7 @@ multiple_of_p (tree type, const_tree top
  && TREE_CODE (op2) == INTEGER_CST
  && integer_pow2p (bottom)
  && wi::multiple_of_p (wi::to_widest (op2),
-   wi::to_widest (bottom), UNSIGNED))
+   wi::to_widest (bottom), SIGNED))
return true;

  op1 = gimple_assign_rhs1 (stmt);
because widest_ints are always signed by definition, or
--- gcc/fold-const.cc.jj2023-11-28 08:46:28.345803059 +0100
+++ gcc/fold-const.cc   2023-11-28 15:43:46.730985893 +0100
@@ -14562,8 +14562,11 @@ multiple_of_p (tree type, const_tree top
  && (op2 = gimple_assign_rhs2 (stmt)) != NULL_TREE
  && TREE_CODE (op2) == INTEGER_CST
  && integer_pow2p (bottom)
- && wi::multiple_of_p (wi::to_widest (op2),
-   wi::to_widest (bottom), UNSIGNED))
+ && wi::multiple_of_p (widest_int::from (wi::to_wide (op2),
+ UNSIGNED),
+   widest_int::from (wi::to_wide (bottom),
+ UNSIGNED),
+   UNSIGNED))
return true;

  op1 = gimple_assign_rhs1 (stmt);
to use widest_int but zero extend there everything, or
--- gcc/fold-const.cc.jj2023-11-28 08:46:28.345803059 +0100
+++ gcc/fold-const.cc   2023-11-28 15:45:35.867445679 +0100
@@ -14562,8 +14562,8 @@ multiple_of_p (tree type, const_tree top
  && (op2 = gimple_assign_rhs2 (stmt)) != NULL_TREE
  && TREE_CODE (op2) == INTEGER_CST
  && integer_pow2p (bottom)
- && wi::multiple_of_p (wi::to_widest (op2),
-   wi::to_widest (bottom), UNSIGNED))
+ && wi::multiple_of_p (wi::to_wide (op2), wi::to_wide (bottom),
+   TYPE_SIGN (TREE_TYPE (bottom
return true;

  op1 = gimple_assign_rhs1 (stmt);
The last one has the disadvantage that it would ICE if op2 and bottom don't
have same precision (but I'd think it would be caller's screw up if that was
the case).

Given
  return wi::multiple_of_p (wi::to_widest (top), wi::to_widest (bottom),
SIGNED);
a few lines earlier in the same patch, I think my preference is the first
patch.
Thoughts on this?

[Bug middle-end/112733] [14 Regression] ICE: Segmentation fault in wide-int.cc during GIMPLE pass: sccp

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

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

--- Comment #6 from Jakub Jelinek  ---
One thing is obviously we shouldn't crash on it and will debug that.
But, what multiple_of_p does (or its callers) is weird:
14552 /* Check for special cases to see if top is defined as
multiple
14553of bottom:
14554   
14555  top = (X & ~(bottom - 1) ; bottom is power of 2
14556   
14557or
14558   
14559  Y = X % bottom
14560  top = X - Y.  */
14561 if (code == BIT_AND_EXPR
14562 && (op2 = gimple_assign_rhs2 (stmt)) != NULL_TREE
14563 && TREE_CODE (op2) == INTEGER_CST
14564 && integer_pow2p (bottom)
14565 && wi::multiple_of_p (wi::to_widest (op2),
14566   wi::to_widest (bottom), UNSIGNED))
14567   return true;
It uses UNSIGNED, but both op2 and bottom are signed:
(gdb) p debug_tree (op2)
 
constant 1>
$17 = void
(gdb) p debug_tree (bottom)
 
constant -128>
so it is in the end multiple_of_p 1,
0xfff80 where the latter has 131072
bits precision.
That definitely doesn't have anything to do with what the source does (and
didn't even when the precision was just 576 bits before).

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

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

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

--- Comment #15 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

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

commit r14-5928-g33b6ce99b54917a910b59dbd643fd223fbba834c
Author: Rainer Orth 
Date:   Tue Nov 28 14:55:52 2023 +0100

libsanitizer: Only use assembler symbol assignment if supported [PR112563]

This patch only enables symbol assignment if the configure test determined
it's supported.

Bootstrapped without regressions on sparc-sun-solaris2.11 (as and gas) and
i386-pc-solaris2.11 (as and gas).

2023-11-23  Rainer Orth  

libsanitizer:
PR sanitizer/112563
* sanitizer_common/sanitizer_redefine_builtins.h: Check
HAVE_AS_SYM_ASSIGN.

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

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

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

--- Comment #14 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:088d3cbc5f906444a7dee98bc9a6f4b724ddfc21

commit r14-5927-g088d3cbc5f906444a7dee98bc9a6f4b724ddfc21
Author: Rainer Orth 
Date:   Tue Nov 28 14:54:34 2023 +0100

libsanitizer: Check assembler support for symbol assignment [PR112563]

The recent libsanitizer import broke the build on Solaris/SPARC with the
native as:

/usr/ccs/bin/as: ".libs/sanitizer_errno.s", line 4247: error: symbol
"__sanitizer_internal_memset" is used but not defined
/usr/ccs/bin/as: ".libs/sanitizer_errno.s", line 4247: error: symbol
"__sanitizer_internal_memcpy" is used but not defined
/usr/ccs/bin/as: ".libs/sanitizer_errno.s", line 4247: error: symbol
"__sanitizer_internal_memmove" is used but not defined

Since none of the alternatives considered in the PR worked out, this
patch checks if the assembler does support symbol assignment, disabling
the code otherwise.  This returns the code to the way it was up to LLVM 16.

Bootstrapped without regressions on sparc-sun-solaris2.11 (as and gas) and
i386-pc-solaris2.11 (as and gas).

2023-11-23  Rainer Orth  

libsanitizer:
PR sanitizer/112563
* configure.ac (libsanitizer_cv_as_sym_assign): Check for
assembler symbol assignment support.
* configure: Regenerate.
* asan/Makefile.am (DEFS): Add @AS_SYM_ASSIGN_DEFS@.
* Makefile.in, asan/Makefile.in, hwasan/Makefile.in,
interception/Makefile.in, libbacktrace/Makefile.in,
lsan/Makefile.in, sanitizer_common/Makefile.in, tsan/Makefile.in,
ubsan/Makefile.in: Regenerate.

[Bug testsuite/112729] gcc.target/i386/apx-interrupt-1.c etc. FAIL

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Hongyu Wang  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #5)
> 
> Is there a reason to have -fomit-frame-pointer once before and once
> after -mapx-features=push2pop2?

Ah, thanks for pointing that out. Will adjust the order to keep them after
-mapx-features.

[Bug middle-end/109849] suboptimal code for vector walking loop

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

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

--- Comment #29 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #28)
> (In reply to Martin Jambor from comment #27)
> > Can you please try if
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638318.html
> > fixes this?
> 
> Testing now ...

Yes, this fixes 21_strings/basic_string/operators/char/* and
28_regex/basic_regex/106607.cc

Running the full testsuite now...

[Bug testsuite/112728] gcc.dg/scantest-lto.c FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Novembe
   ||r/638465.html

--- Comment #1 from Rainer Orth  ---
Patch for Solaris/SPARC as issue posted.

[Bug debug/111409] Invalid .debug_macro.dwo macro information for split DWARF

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

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #3 from Rainer Orth  ---
The new test FAILs on a couple of targets (sparc-sun-solaris2.11,
powerpc-ibm-aix7.2.5.0, hppa64-hp-hpux11.11).  I've commited a patch for the
Solaris/SPARC (and probably AIX) issue:

https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638456.html

HP/UX seems to be different, however.

Besides, is there a reason this PR is still open?

[Bug middle-end/109849] suboptimal code for vector walking loop

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

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

--- Comment #28 from Jonathan Wakely  ---
(In reply to Martin Jambor from comment #27)
> Unfortunately I cannot reproduce this, the above (on pristine master
> commit 006e90e1344 on an x86_64-linux) results in:
> 
> Running target unix/-D_GLIBCXX_USE_CXX11_ABI=0
> Running
> /home/mjambor/gcc/small/src/libstdc++-v3/testsuite/libstdc++-dg/conformance.
> exp ...
> PASS: 21_strings/basic_string/operators/char/1.cc  -std=gnu++17 (test for
> excess errors)
> PASS: 21_strings/basic_string/operators/char/1.cc  -std=gnu++17 execution
> test

Oops, sorry, that particular FAIL needs either
--target_board=unix/-D_GLIBCXX_USE_CXX11_ABI=0/-D_GLIBCXX_DEBUG which then
makes it fail for all -std modes:


Schedule of variations:
unix/-D_GLIBCXX_USE_CXX11_ABI=0/-D_GLIBCXX_DEBUG

Running target unix/-D_GLIBCXX_USE_CXX11_ABI=0/-D_GLIBCXX_DEBUG
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /home/test/src/gcc/libstdc++-v3/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /home/test/src/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
FAIL: 21_strings/basic_string/operators/char/1.cc  -std=gnu++11 execution test
FAIL: 21_strings/basic_string/operators/char/1.cc  -std=gnu++14 execution test
FAIL: 21_strings/basic_string/operators/char/1.cc  -std=gnu++17 execution test
FAIL: 21_strings/basic_string/operators/char/1.cc  -std=gnu++20 execution test
FAIL: 21_strings/basic_string/operators/char/1.cc  -std=gnu++23 execution test
FAIL: 21_strings/basic_string/operators/char/1.cc  -std=gnu++26 execution test

Or just set GLIBCXX_TESTSUITE_STDS="17,20" in the env before running the test:

Schedule of variations:
unix/-D_GLIBCXX_USE_CXX11_ABI=0

Running target unix/-D_GLIBCXX_USE_CXX11_ABI=0
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /home/test/src/gcc/libstdc++-v3/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /home/test/src/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
FAIL: 21_strings/basic_string/operators/char/1.cc  -std=gnu++20 execution test

It seems I picked a bad example to give, which requires additional options to
FAIL.

Many of the other FAILs do not require _GLIBCXX_DEBUG or -std=gnu++20 to FAIL,
but the -D_GLIBCXX_USE_CXX11_ABI=0 option is necessary, at least for all the
ones I inspected. That option isn't used by default, but I run the full
testsuite with that several times a day, and with
GLIBCXX_TESTSUITE_STDS=98,11,14,17,20,23,26.


> Can you please try if
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638318.html
> fixes this?

Testing now ...

[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94

[manolis.tsamis at vrull dot eu via Gcc-bugs]

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

--- Comment #52 from Manolis Tsamis  ---
(In reply to Sam James from comment #51)
> manolis, did you have a chance to look at the remaining pass issue? You'll
> need to revert Dave's commit locally which made the issue latent for
> building Python.

Hi Sam, I had to work on some other things so I didn't get to find a fix yet,
but I'll be working on that again now (in light of the new info from PR111601
too). 

Thanks for the ping,
Manolis

[Bug testsuite/112729] gcc.target/i386/apx-interrupt-1.c etc. FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Novembe
   ||r/638447.html

--- Comment #6 from Rainer Orth  ---
Patch for the cfi directive issue posted.

[Bug testsuite/112729] gcc.target/i386/apx-interrupt-1.c etc. FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Hongyu Wang  ---
[...]
> Hi Rainer, can you help verify if the change make these test pass on
> solaris/FreeBSD?

They do on Solaris/x86.  Thanks.

FreeBSD was more involved (I'd only noticed the failure there on
gcc-testresults).  Unfortunately, there's no FreeBSD/x86_64 system in
the cfarm.  However, I had an old FreeBSD 13 VM around which could be
coaxed into a gcc build with some effort.  With your patch, the failures
are gone there, too.

One nit:

diff --git a/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
b/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
index d78c96d36a3..1d73aab1128 100644
--- a/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
+++ b/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { ! ia32 } } } */
-/* { dg-options "-O2 -mapx-features=push2pop2" } */
+/* { dg-options "-O2 -fomit-frame-pointer -mapx-features=push2pop2" } */
 /* { dg-skip-if "does not emit .cfi_xxx" "*-*-darwin*" } */

 extern int bar (int);
diff --git a/gcc/testsuite/gcc.target/i386/apx-push2pop2_force_drap-1.c
b/gcc/testsuite/gcc.target/i386/apx-push2pop2_force_drap-1.c
index 3cac7b10769..4e2259f0c99 100644
--- a/gcc/testsuite/gcc.target/i386/apx-push2pop2_force_drap-1.c
+++ b/gcc/testsuite/gcc.target/i386/apx-push2pop2_force_drap-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { ! ia32 } } } */
-/* { dg-options "-O2 -mapx-features=push2pop2 -mforce-drap" } */
+/* { dg-options "-O2 -mapx-features=push2pop2 -fomit-frame-pointer
-mforce-drap" } */
 /* { dg-skip-if "does not emit .cfi_xxx" "*-*-darwin*" } */

 #include "apx-push2pop2-1.c"

Is there a reason to have -fomit-frame-pointer once before and once
after -mapx-features=push2pop2?

[Bug tree-optimization/112736] [14 Regression] vectorizer is introducing out of bounds memory access

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
The vectorizer sees

   [local count: 214748368]:
  # a.3_5 = PHI <_2(5), 2(2)>
  # ivtmp_9 = PHI 
  _14 = b[a.3_5];
  c[a.3_5][0] = _14;
  c[a.3_5][1] = _14;
  c[a.3_5][2] = _14;
  c[a.3_5][3] = _14;
  _2 = a.3_5 + -1;
  ivtmp_3 = ivtmp_9 - 1;
  if (ivtmp_3 != 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 191126048]:
  goto ; [100.00%]

and uses SLP, this is likely caused by my patch to allow non-grouped-loads
there.

t.c:7:17: note:   node 0x4637048 (max_nunits=4, refcnt=1) vector(4) int
t.c:7:17: note:   op template: _14 = b[a.3_5];
t.c:7:17: note: stmt 0 _14 = b[a.3_5];
t.c:7:17: note: stmt 1 _14 = b[a.3_5];
t.c:7:17: note: stmt 2 _14 = b[a.3_5];
t.c:7:17: note: stmt 3 _14 = b[a.3_5];
t.c:7:17: note: load permutation { 0 0 0 0 }

I think we need to force strided-SLP for them.