[Bug target/113625] Interesting behavior with and without -mcpu=generic

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

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

--- Comment #1 from Richard Biener  ---
Other targets (x86_64) default to -mtune=generic.  Maybe configure time
selection somehow interferes with this on aarch64?

[Bug c++/113649] New: ICE: nested template class template argument deduction

[schaumb at gmail dot com via Gcc-bugs]

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

Bug ID: 113649
   Summary: ICE: nested template class template argument deduction
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: schaumb at gmail dot com
  Target Milestone: ---

The following code does not compile, see here https://godbolt.org/z/vz5KMzhsh:


template
struct params {
template 
struct return_type {
constexpr return_type(Return (*p1)(Ts...)){}
};

template 
return_type(Return (*)(Ts...)) -> 
return_type;


template
struct addr {};
};

void x(double);

template struct params::addr<>;


It runs to internal compiler error:

:19:40: internal compiler error: in build_function_type, at
tree.cc:7488
   19 | template struct params::addr<>;
  |^
0x2647edc internal_error(char const*, ...)
???:0
0xa51cb7 fancy_abort(char const*, int, char const*)
???:0
0xc72375 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int, tree_node*)
???:0
0xc76223 coerce_template_parms(tree_node*, tree_node*, tree_node*, int, bool)
???:0
0xc93089 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0xccf8ff finish_template_type(tree_node*, tree_node*, int)
???:0
0xc53d2a c_parse_file()
???:0
0xda79a9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

[Bug tree-optimization/113622] [11/12/13/14 Regression] ICE with vectors in named registers

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
I will have a look.

[Bug target/113618] [14 Regression] AArch64: memmove idiom regression

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

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

--- Comment #2 from Richard Biener  ---
It might be good to recognize this pattern in strlenopt or a related pass.

A purely local transform would turn it into

memcpy (temp, a, 64);
memmove (b, a, 64);

relying on DSE to eliminate the copy to temp if possible.  Not sure if
that possibly would be a bad transform if copying to temp is required.

stp q30, q31, [sp]
ldp q30, q31, [sp]

why is CSE not able to catch this?

[Bug debug/103047] Inconsistent arguments ordering for inlined subroutine

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||14.0
   Target Milestone|--- |14.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Richard Biener  ---
Fixed for GCC 14.

[Bug debug/103047] Inconsistent arguments ordering for inlined subroutine

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

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

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

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

commit r14-8486-gb702dc980215074a06535e3aa52a766bef38af4c
Author: Richard Biener 
Date:   Fri Jan 26 15:11:47 2024 +0100

debug/103047 - argument order of inlined functions

The inliner puts variables for parameters of the inlined functions
in the inline scope in reverse order.  The following reverses them
again so that we get consistent ordering between the
DW_TAG_subprogram DW_TAG_formal_parameter and the
DW_TAG_inlined_subroutine DW_TAG_formal_parameter set.

I failed to create a testcase with regexps since the inline
instances have just abstract origins and so I can't match them up.

PR debug/103047
* tree-inline.cc (initialize_inlined_parameters): Reverse
the decl chain of inlined parameters.

[Bug target/108493] Interaction with builtin_defines (on PowerPC) and -traditional-cpp

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||gaius at gcc dot gnu.org

--- Comment #3 from Gaius Mulley  ---
I wonder if writing a filter program to strip comments out before cpp would fix
the problem.

The filter program (m2decom) would strip out any comment which does not have
'#' in the first column (and honour line continuation backslashes etc).  This
would allow the debugging technique in gcc/m2/gm2-libs/FormatStrings.mod to
work.

If I recall correctly the reason cpp -traditional is required is because ' is a
start of string character in m2 (so is ").  But the m2 string formed: '\'
causes:

$ gcc -x c -E ~/GCC/gcc-read-write/gcc/m2/gm2-libs/FormatStrings.mod
   
   DSdbEnter ;
   d := InitString ('') ;
/home/gaius/GCC/gcc-read-write/gcc/m2/gm2-libs/FormatStrings.mod:196:19:
warning: missing terminating ' character
  196 |i := Index (s, '\', 0) ;
  |   ^
   i := Index (s, '\', 0) ;

[Bug target/113648] Cross compiler cannot find cross binutils on macOS

[galaxyking0419 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from William Tang  ---
(In reply to Andrew Pinski from comment #1)
> Works for me for a cross from Linux:
> [apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc
> -print-prog-name=ld
> /bajas/pinskia/src/upstream-full-cross/install/bin/../lib/gcc/aarch64-linux-
> gnu/14.0.1/../../../../aarch64-linux-gnu/bin/ld
> 
> My configure line:
> Configured with: ../configure --target=aarch64-linux-gnu
> --prefix=/home/apinski/src/upstream-full-cross/install
> --enable-languages=c,c++,fortran,go
> --with-sysroot=/home/apinski/src/upstream-full-cross/install//sysroot
> 
> 
> Can you do:
> provide the output of `strace aarch64-linux-gnu-gcc -print-prog-name=ld ` ?
> 
> Also provide the config.log from the original build?

[u@h d]% sudo dtruss aarch64-linux-gnu-gcc -print-prog-name=ld
SYSCALL(args)= return
ld
munmap(0x1047A, 0x98000) = 0 0
munmap(0x104838000, 0x8000)  = 0 0
munmap(0x10484, 0x4000)  = 0 0
munmap(0x104844000, 0x4000)  = 0 0
munmap(0x104848000, 0x5C000) = 0 0
crossarch_trap(0x0, 0x0, 0x0)= -1 Err#45
fsgetpath(0x16B8F31C8, 0x400, 0x16B8F31A8)   = 53 0
fsgetpath(0x16B8F31D8, 0x400, 0x16B8F31B8)   = 14 0
csrctl(0x0, 0x16B8F35DC, 0x4)= -1 Err#1
__mac_syscall(0x18AF5E948, 0x2, 0x16B8F3520) = 0 0
csrctl(0x0, 0x16B8F35FC, 0x4)= -1 Err#1
__mac_syscall(0x18AF5B79E, 0x5A, 0x16B8F3590)= 0 0
sysctl([unknown, 3, 0, 0, 0, 0] (2), 0x16B8F2AF8, 0x16B8F2AF0, 0x18AF5D3EF,
0xD) = 0 0
sysctl([CTL_KERN, 137, 0, 0, 0, 0] (2), 0x16B8F2BA8, 0x16B8F2BA0, 0x0, 0x0)
 = 0 0
open("/\0", 0x2010, 0x0) = 3 0
openat(0x3, "System/Cryptexes/OS\0", 0x10, 0x0)  = 4 0
dup(0x4, 0x0, 0x0)   = 5 0
fstatat64(0x4, 0x16B8F2681, 0x16B8F25F0) = 0 0
openat(0x4, "System/Library/dyld/\0", 0x10, 0x0) = 6 0
fcntl(0x6, 0x32, 0x16B8F2680)= 0 0
dup(0x6, 0x0, 0x0)   = 7 0
dup(0x5, 0x0, 0x0)   = 8 0
close(0x3)   = 0 0
close(0x5)   = 0 0
close(0x4)   = 0 0
close(0x6)   = 0 0
shared_region_check_np(0x16B8F2C90, 0x0, 0x0)= 0 0
fsgetpath(0x16B8F31E0, 0x400, 0x16B8F3138)   = 82 0
fcntl(0x8, 0x32, 0x16B8F31E0)= 0 0
close(0x8)   = 0 0
close(0x7)   = 0 0
getfsstat64(0x0, 0x0, 0x2)   = 11 0
getfsstat64(0x104B72040, 0x5D28, 0x2)= 11 0
getattrlist("/\0", 0x16B8F3110, 0x16B8F3080) = 0 0
stat64("/System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_arm64e\0",
0x16B8F3470, 0x0)  = 0 0
dtrace: error on enabled probe ID 1690 (ID 845: syscall::stat64:return):
invalid address (0x0) in action #11 at DIF offset 12
stat64("/Volumes/Toolchain/openwrt/bin/aarch64-linux-gnu-gcc\0", 0x16B8F2920,
0x0)   = 0 0
open("/Volumes/Toolchain/openwrt/bin/aarch64-linux-gnu-gcc\0", 0x0, 0x0)   
 = 3 0
mmap(0x0, 0x259A38, 0x1, 0x40002, 0x3, 0x0)  = 0x104BB4000 0
fcntl(0x3, 0x32, 0x16B8F2A38)= 0 0
close(0x3)   = 0 0
munmap(0x104BB4000, 0x259A38)= 0 0
stat64("/Volumes/Toolchain/openwrt/bin/aarch64-linux-gnu-gcc\0", 0x16B8F2E90,
0x0)   = 0 0
stat64("/usr/lib/libiconv.2.dylib\0", 0x16B8F1E20, 0x0)  = -1 Err#2
stat64("/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libiconv.2.dylib\0",
0x16B8F1DD0, 0x0)  = -1 Err#2
stat64("/usr/lib/system/libdispatch.dylib\0", 0x16B8EFA30, 0x0)  = -1
Err#2
stat64("/System/Volumes/Preboot/Cryptexes/OS/usr/lib/system/libdispatch.dylib\0",
0x16B8EF9E0, 0x0)  = -1 Err#2
stat64("/usr/lib/system/libdispatch.dylib\0", 0x16B8EFA30, 0x0)  = -1
Err#2
stat64("/usr/lib/libc++.1.dylib\0", 0x16B8F1E20, 0x0)= -1 Err#2
stat64("/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libc++.1.dylib\0",
0x16B8F1DD0, 0x0)= -1 Err#2
stat64("/usr/lib/libSystem.B.dylib\0", 0x16B8F1E20, 0x0) = -1
Err#2
stat64("/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libSystem.B.dylib\0",
0x16B8F1DD0, 0x0) = -1 Err#2
open("/dev/dtracehelper\0", 0x2, 0x0)= 3 0
ioctl(0x3, 0x80086804, 0x16B8F19C8)  = 0 0
close(0x3)   = 0 0
open("/Volumes/Toolchain/openwrt/bin/aarch64-linux-gnu-gcc\0", 0x0, 0x0)   
 = 3 0
__mac_syscall(0x18AF5E948, 0x2, 0x16B8F10D0) = 0 0
map_with_linking_np(0x16B8EEC60, 0x1, 0x16B8EEC90)   = 0 0
close(0x3)   = 0 0
mprotect(0x1046B, 0x3C000, 0x1)  = 0 0
shared_region_check_np(0x, 0x0, 0x0) = 0 0
mprotect(0x104B7, 0x4, 0x1)  = 0 0
access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0) = -1 Err#2
bsdthread_register(0x18B24CE34, 

[Bug debug/113636] [14 Regression] internal compiler error: in dead_debug_global_find, at valtrack.cc:275

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #7 from Andrew Pinski  ---
Looks like it is early RA which exposing/causing this.

Adding `-mearly-ra=none` to the command line causes the ICE to go away.

I tried to create a C testcase but I am unable to so far. Plus it requires
debugging info so it is harder to recreate with inlining and such.

[Bug target/113648] Cross compiler cannot find cross binutils on macOS

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-01-29
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
Works for me for a cross from Linux:
[apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc
-print-prog-name=ld
/bajas/pinskia/src/upstream-full-cross/install/bin/../lib/gcc/aarch64-linux-gnu/14.0.1/../../../../aarch64-linux-gnu/bin/ld

My configure line:
Configured with: ../configure --target=aarch64-linux-gnu
--prefix=/home/apinski/src/upstream-full-cross/install
--enable-languages=c,c++,fortran,go
--with-sysroot=/home/apinski/src/upstream-full-cross/install//sysroot


Can you do:
provide the output of `strace aarch64-linux-gnu-gcc -print-prog-name=ld ` ?

Also provide the config.log from the original build?

[Bug target/113648] New: Cross compiler cannot find cross binutils on macOS

[galaxyking0419 at gmail dot com via Gcc-bugs]

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

Bug ID: 113648
   Summary: Cross compiler cannot find cross binutils on macOS
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: galaxyking0419 at gmail dot com
  Target Milestone: ---

According to https://gcc.gnu.org/install/configure.html, the gcc should find
binutils components (e.g., as, ld, objdump) using rule:
- Unless GCC is being built with a cross compiler, check the
libexec/gcc/target/version directory. libexec defaults to exec-prefix/libexec;
exec-prefix defaults to prefix, which defaults to /usr/local unless overridden
by the --prefix=pathname switch described above. target is the target system
triple, such as ‘sparc-sun-solaris2.11’, and version denotes the GCC version,
such as 3.0. If the target system is the same that you are building on, check
operating system specific directories.
- Check in the PATH for a tool whose name is prefixed by the target system
triple.
- Check in the PATH for a tool whose name is not prefixed by the target system
triple, if the host and target system triple are the same (in other words, we
use a host tool if it can be used for the target as well).

My setup following the target system triple convention:
[u@mbp d]% whereis aarch64-linux-gnu-ld
aarch64-linux-gnu-ld: /Volumes/Toolchain/openwrt/bin/aarch64-linux-gnu-ld

But the aarch64-linux-gnu-gcc still picks the macOS as, ld etc:
[u@mbp d]% aarch64-linux-gnu-gcc -print-prog-name=ld
ld
[u@mbp d]% aarch64-linux-gnu-gcc -print-prog-name=as
as
[u@mbp d]% aarch64-linux-gnu-gcc -print-prog-name=objdump
objdump

GCC configuration:
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/Volumes/Toolchain/openwrt/lib/gcc/aarch64-linux-gnu/13.2.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../gcc-13.2.0/configure --disable-libgomp
--disable-libquadmath --disable-libsanitizer --disable-libssp
--disable-libstdcxx-pch --disable-libunwind-exceptions --disable-multilib
--disable-nls --disable-werror --enable-__cxa_atexit --enable-checking=release
--enable-clocale=gnu --enable-default-pie --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-languages=c,c++
--enable-lto --enable-shared --enable-threads=posix
--libexecdir=/Volumes/Toolchain/openwrt/lib --prefix=/Volumes/Toolchain/openwrt
--program-prefix=aarch64-linux-gnu- --target=aarch64-linux-gnu
--with-build-sysroot=/Volumes/Toolchain/openwrt/aarch64-linux-gnu
--with-cpu=cortex-a53+crypto --with-glibc-version=2.38 --with-gmp=/opt/homebrew
--with-mpc=/opt/homebrew --with-mpfr=/opt/homebrew
--with-local-prefix=/Volumes/Toolchain/openwrt/aarch64-linux-gnu
--with-sysroot=/Volumes/Toolchain/openwrt/aarch64-linux-gnu --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)

[Bug debug/113636] [14 Regression] internal compiler error: in dead_debug_global_find, at valtrack.cc:275

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

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

--- Comment #6 from Andrew Pinski  ---
Created attachment 57248
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57248=edit
Reduced so far

But this might still need some external modules, need to understand that ...

[Bug debug/113636] [14 Regression] internal compiler error: in dead_debug_global_find, at valtrack.cc:275

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||needs-reduction

--- Comment #5 from Andrew Pinski  ---
Trying to reduce this slightly.

[Bug debug/113636] [14 Regression] internal compiler error: in dead_debug_global_find, at valtrack.cc:275

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

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

--- Comment #4 from Andrew Pinski  ---
Just FYI (just recording on how to reproduce it once the build is finished,
needed to modify some scripts to get the command line out in the first place):

cd /home/apinski/src/upstream-full-cross/gcc/libgo/go/math/cmplx

/home/apinski/src/upstream-full-cross/gcc/objdir-stage2/./gcc/gccgo
-B/home/apinski/src/upstream-full-cross/gcc/objdir-stage2/./gcc/
-B/home/apinski/src/upstream-full-cross/install/aarch64-linux-gnu/bin/
-B/home/apinski/src/upstream-full-cross/install/aarch64-linux-gnu/lib/ -isystem
/home/apinski/src/upstream-full-cross/install/aarch64-linux-gnu/include
-isystem
/home/apinski/src/upstream-full-cross/install/aarch64-linux-gnu/sys-include -g
-O2 -L
/home/apinski/src/upstream-full-cross/gcc/objdir-stage2/aarch64-linux-gnu/libgo
-L
/home/apinski/src/upstream-full-cross/gcc/objdir-stage2/aarch64-linux-gnu/libgo/.libs
-g -fgo-pkgpath=math/cmplx -c -I . -fno-toplevel-reorder -o _gotest_.o
cmath_test.go huge_test.go abs.go asin.go conj.go exp.go isinf.go isnan.go
log.go phase.go polar.go pow.go rect.go sin.go sqrt.go tan.go

[Bug debug/113636] [14 Regression] internal compiler error: in dead_debug_global_find, at valtrack.cc:275

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

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

--- Comment #3 from Andrew Pinski  ---
Started between r14-5889-c9d691a7daa162d6d2092 and r14-6443-g3e93a3f09dc I
think.

[Bug debug/113636] [14 Regression] internal compiler error: in dead_debug_global_find, at valtrack.cc:275

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|internal compiler error: in |[14 Regression] internal
   |dead_debug_global_find, at  |compiler error: in
   |valtrack.cc:275 |dead_debug_global_find, at
   ||valtrack.cc:275
   Target Milestone|--- |14.0

--- Comment #2 from Andrew Pinski  ---
It has been failing since at least `Wed Dec 13 06:06:19 UTC 2023` for me.

[Bug debug/113636] internal compiler error: in dead_debug_global_find, at valtrack.cc:275

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||aarch64-linux-gnu

--- Comment #1 from Andrew Pinski  ---
I can reproduce this with a cross to aarch64-linux-gnu too.

[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #23 from Andrew Pinski  ---
The testcase now has the corrected check and the check has been fixed (at least
for powerpc* and aarch64) so closing as fixed.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

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

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

--- Comment #15 from JuzheZhong  ---
Hi, Robin.

I tried to disable vec_extract, then the case passed.

diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 3b32369f68c..b61b886ef3d 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -1386,7 +1386,7 @@
(match_operand:V_VLS  1 "register_operand")
(parallel
 [(match_operand  2 "nonmemory_operand")])))]
-  "TARGET_VECTOR"
+  "0"
 {
   /* Element extraction can be done by sliding down the requested element
  to index 0 and then v(f)mv.[xf].s it to a scalar register.  */


I am not so familiar with it (vec extract stuff), could you take a look at it ?

[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4

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

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

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

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

commit r14-8485-g5b393ac7f1715328ee92236071edc3885bf53317
Author: Andrew Pinski 
Date:   Sun Jan 28 20:35:05 2024 -0600

testsuite: Fix vect_long_mult for 32-bit Power [PR109705]

As PR109705#c17, commit r14-7270 missed to consider long
type is 32bit with option -m32.  This patch is take care of
it accordingly.

Note that the vect_long_mult is supposed to be only used in
vect/ (generic), powerpc_altivec_ok would be guaranteed.

PR testsuite/109705

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_vect_long_mult):
Fix powerpc*-*-* checks by considering ilp32.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/113639] ICE: in handle_operand_addr, at gimple-lower-bitint.cc:2265 at -O with _BitInt() in a struct

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed.  This looks like another SRA issue.

SRA produces:
```
  _BitInt(192) s;
  _BitInt(129) _1;

   :
  s_10 = MEM[(struct S *)];
  _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(s_10);

```

Note I did s/418/129/ to make easier to reproduce on all targets that support
_BitInt (which is still just x86_64).

[Bug middle-end/107845] __builtin_init_trampoline ICEs on invalid arguments

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Gabriel Ravier  ---
I'll add that the new `__builtin_init_heap_trampoline` builtin also ICEs when
given the same arguments, presumably for the same reasons (thus, an extra bug
report doesn't seem very useful)

[Bug c/113647] __builtin_eh_return_data_regno ICEs when passed -1 as argument

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug middle-end/101195] ICE: in tree_to_uhwi, at tree.c:6324

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gabravier at gmail dot com

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

[Bug c/113647] New: __builtin_eh_return_data_regno ICEs when passed -1 as argument

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 113647
   Summary: __builtin_eh_return_data_regno ICEs when passed -1 as
argument
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f()
{
return __builtin_eh_return_data_regno(-1);
}

This crashes GCC with the following error:

during RTL pass: expand
: In function 'int f()':
:440:42: internal compiler error: in tree_to_uhwi, at tree.cc:6472
  440 | return __builtin_eh_return_data_regno(-1);
  |~~^~~~
0x2647edc internal_error(char const*, ...)
???:0
0xa51cb7 fancy_abort(char const*, int, char const*)
???:0
0xf34aa6 expand_builtin_eh_return_data_regno(tree_node*)
???:0
0xf6381c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0xf6ef5e store_expr(tree_node*, rtx_def*, int, bool, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

This seems to be due to the following code:

```
rtx
expand_builtin_eh_return_data_regno (tree exp)
{
  tree which = CALL_EXPR_ARG (exp, 0);
  unsigned HOST_WIDE_INT iwhich;

  if (TREE_CODE (which) != INTEGER_CST)
{
  error ("argument of %<__builtin_eh_return_regno%> must be constant");
  return constm1_rtx;
}

  iwhich = tree_to_uhwi (which); // <-- THIS
```

wherein it looks like `tree_to_uhwi` asserts that its argument is non-negative,
meaning -1 (and all other negative numbers) fail.

[Bug c++/113638] [13/14 Regression] Array bounds of variable templates are not correctly deduced from initializers since GCC13 inside a decltype/sizeof

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

Simplified testcase:
```
template
constexpr int my_array[]{Is...};
constexpr auto t1 = my_array<2>;
static_assert(sizeof(my_array<1>) == sizeof(int) * 1);
```

If we change the t1 variable definition to use `my_array<1>` instead of
`my_array<2>`, then the sizeof works.

It seems like we are not fully instantiating the template variable when used
inside a decltype/sizeof to figure out the array bounds.

An obvious workaround is to do:
```
template
constexpr int my_array[sizeof...(Is)]{Is...};
```

[Bug libgomp/110813] [OpenMP] omp_target_memcpy_rect (+ strided 'target update'): Improve GCN performance and contiguous subranges

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

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

--- Comment #4 from Tobias Burnus  ---
The GCN specific part has been applied to
GCC 14 mainline in commit:
https://gcc.gnu.org/g:a17299c17afeb92a56ef716d2d6380c8538493c4

Unhandled:

* Strided and optimized strided copy (incl. generic part of the linked comment
3, which still needs to be comitted), the former is "[PATCH 0/5] OpenMP:
Array-shaping operator and strided/rectangular 'target update' support",
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629422.html

* Consider also to use a library function for *inter*-device copy if the device
type or the function pointer is the same.

[Bug gcov-profile/113646] New: PGO hurts run-time of 538.imagick_r as much as 68% at -Ofast -march=native

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

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

Bug ID: 113646
   Summary: PGO hurts run-time of 538.imagick_r as much as 68% at
-Ofast -march=native
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux, aarch64-linux
Target: x86_64-linux, aarch64-linux

Using profile guided optimization is very detrimental when compiling SPEC 2017
FPrate benchmark 538.imagick_r at -Ofast -march=native (with or without LTO) on
all machines where I have tried.

On Zen4, using PGO results in a 68% slower than not doing that without LTO and
65% with LTO:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=970.507.0=966.507.0=959.507.0=958.507.0;

On Zen3, using PGO slows the binary down by 22% when not using LTO and by 30%
with LTO:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=471.507.0=473.507.0=475.507.0=477.507.0;

On Zen2, PGO regresses by 16% without LTO and by 28% with it:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=295.507.0=293.507.0=287.507.0=286.507.0;

On our Altra CPU, the slowdowns are 26% and 45%:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=584.507.0=583.507.0=587.507.0=589.507.0;

On an Intel CascadeLake machine, they are 24% and 41%. (Our LNT Intel machine
is temporarily offline, unfortunately).

It is of course possible that the training workload does not match the
reference one very well.  However, this was not a problem in the past
(apparently the problem is that our non-PGO results improved but our PGO ones
did not).  Also, other compilers such as LLVM achieve better run-times with PGO
than without.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug c++/113644] [14 regression] ICE when building libcxxabi-16.0.6 since r14-6520

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

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

--- Comment #4 from Sam James  ---
cvise gave me:
```
template  class __bit_reference;
template  struct __bit_reference<_Cp, false> {
  class __bit_reference<_Cp>;
};
```

gcc doesn't warn on it, but clang does

[Bug c++/113644] [14 regression] ICE when building libcxxabi-16.0.6 since r14-6520

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
Summary|[14 regression] ICE when|[14 regression] ICE when
   |building libcxxabi-16.0.6   |building libcxxabi-16.0.6
   ||since r14-6520
 CC||jakub at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r14-6520-g35ba3add7d0a9fc6ce955ba8ad82b0413e86ad7d

[Bug c++/113644] [14 regression] ICE when building libcxxabi-16.0.6

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Target Milestone|--- |14.0

[Bug c++/113644] [14 regression] ICE when building libcxxabi-16.0.6

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I almost want to say the underlying issue with this one is the same as PR
106052 .

[Bug c++/113644] [14 regression] ICE when building libcxxabi-16.0.6

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

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

--- Comment #1 from Andrew Pinski  ---
Reduced:
```
template  struct __has_storage_type {};
template ::value>
class __bit_reference {};
template  class __bit_reference<_Cp, false> {
  friend class __bit_reference<_Cp>;
};

```

[Bug target/113615] internal compiler error: in extract_insn, at recog.cc:2812

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||ams at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
> I'm seeing a lot of ICEs like this when running libgomp testsuite with
> offloading for gfx1030.

I wonder why Andrew S didn't see them (unless he did?). However, I did get a
similar/the same ICE for the testcase in PR113645.

I have not checked whether anything below applies to the PR as well or not but
as Andrew P has marked it as duplicate ...

* * *

Regarding PR113645: While, I have no real idea about GCC backend handling, the
following SEEMS TO FIX THE ISSUE for the ICE of the testcase with -O3 and
gfx1030 and gfx1100, also known as

possible patch:

--- a/gcc/config/gcn/gcn-valu.md
+++ b/gcc/config/gcn/gcn-valu.md
@@ -4273,9 +4273,10 @@
 (define_expand "fold_left_plus_"
  [(match_operand: 0 "register_operand")
   (match_operand: 1 "gcn_alu_operand")
   (match_operand:V_FP 2 "gcn_alu_operand")]
-  "can_create_pseudo_p ()
+  "!TARGET_RDNA2_PLUS
+   && can_create_pseudo_p ()
&& (flag_openacc || flag_openmp
|| flag_associative_math)"
   {
 rtx dest = operands[0];

[Bug fortran/113377] Wrong code passing optional dummy argument to elemental procedure with optional dummy

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

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

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

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

commit r14-8479-gc4773944bb3bec712b4002a2e599409301e50b11
Author: Harald Anlauf 
Date:   Thu Jan 25 22:19:10 2024 +0100

Fortran: NULL actual to optional dummy with VALUE attribute [PR113377]

gcc/fortran/ChangeLog:

PR fortran/113377
* trans-expr.cc (conv_dummy_value): Treat NULL actual argument to
optional dummy with the VALUE attribute as not present.
(gfc_conv_procedure_call): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/113377
* gfortran.dg/optional_absent_11.f90: New test.

[Bug target/113615] internal compiler error: in extract_insn, at recog.cc:2812

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

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

[Bug target/113645] [amdgcn][gfx1030][gfx1100] ICE in RTL pass: vregs with -O3: unrecognizable insn (vector reductions)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug target/113645] New: [amdgcn][gfx1030][gfx1100] ICE in RTL pass: vregs with -O3: unrecognizable insn (vector reductions)

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

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

Bug ID: 113645
   Summary: [amdgcn][gfx1030][gfx1100] ICE in RTL pass: vregs with
-O3: unrecognizable insn (vector reductions)
   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: burnus at gcc dot gnu.org
CC: ams at gcc dot gnu.org
  Target Milestone: ---
Target: amdgcn-amdhsa

Created attachment 57247
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57247=edit
Testcase, compile with gcc -fopenmp -O3 -foffload-options=-march=gfx1030 or
gfx1100

Found for BabelStream when compiling with AMD GPU offloading for gfx1030 or
gfx1100 and using -O3.

# git clone https://github.com/UoB-HPC/BabelStream
# cd BabelStream; mkdir build; cd build
# cmake .. -DMODEL=omp
-DCMAKE_CXX_COMPILER=$HOME/projects/gcc-trunk-offload/bin/g++ -DOFFLOAD=ON
-DCXX_EXTRA_FLAGS=-foffload=amdgcn-amdhsa=-march=gfx1100 -fopenmp
# make

 * * *

Simplified testcase attached, compile with:

gcc  -fopenmp -foffload=amdgcn-amdhsa \
 -foffload-options=amdgcn-amdhsa=-march=gfx1030 -O3

or, likewise, gfx1100.

 * * *

foo.c:5:9: error: unrecognizable insn:
5 |   #pragma omp target teams distribute parallel for simd map(tofrom:
sum) reduction(+:sum)
  | ^
(insn 144 143 145 10 (set (reg:V16SF 926)
(unspec:V16SF [
(reg:V16SF 922) repeated x2
(const_int 1 [0x1])
] UNSPEC_PLUS_DPP_SHR)) "foo.c":5:9 -1
 (nil))
during RTL pass: vregs
foo.c:5:9: internal compiler error: in extract_insn, at recog.cc:2812
0x7f6b21 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/tob/repos/gcc/gcc/rtl-error.cc:108
0x7f6b3d _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/tob/repos/gcc/gcc/rtl-error.cc:116
0x7f55e4 extract_insn(rtx_insn*)
/home/tob/repos/gcc/gcc/recog.cc:2812
0xb6b860 instantiate_virtual_regs_in_insn
/home/tob/repos/gcc/gcc/function.cc:1611
0xb6b860 instantiate_virtual_regs
/home/tob/repos/gcc/gcc/function.cc:1994
0xb6b860 execute
/home/tob/repos/gcc/gcc/function.cc:2041

[Bug c++/113638] [13/14 Regression] Array bounds of variable templates are not correctly deduced from initializers since GCC13

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.3
Summary|Array bounds of variable|[13/14 Regression] Array
   |templates are not correctly |bounds of variable
   |deduced from initializers   |templates are not correctly
   |since GCC13 |deduced from initializers
   ||since GCC13

[Bug c++/113644] New: [14 regression] ICE when building libcxxabi-16.0.6

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

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

Bug ID: 113644
   Summary: [14 regression] ICE when building libcxxabi-16.0.6
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57246
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57246=edit
cxa_demangle.cpp.ii.xz

Originally reported downstream in Gentoo at https://bugs.gentoo.org/923111 by
Toralf Förster.

```
FAILED: libcxxabi/src/CMakeFiles/cxxabi_static_objects.dir/cxa_demangle.cpp.o
/usr/lib/ccache/bin/g++ -m32 -mfpmath=sse -DLIBCXX_BUILDING_LIBCXXABI
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LIBCPP_BUILDING_LIBRARY
-D_LIBCXXABI_BUILDING_LIBRARY -D__STDC_CONSTANT_MACROS -D__STDC_FORM
AT_MACROS -D__STDC_LIMIT_MACROS
-I/var/tmp/portage/sys-libs/libcxxabi-16.0.6/work/libcxxabi/../libcxx/src
-I/var/tmp/portage/sys-libs/libcxxabi-16.0.6/work/runtimes_build-abi_x86_32.x86/include/c++/v1
-I/var/
tmp/portage/sys-libs/libcxxabi-16.0.6/work/libcxxabi/include  -O3 -march=znver3
-fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra
-Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field
-initializers -Wimplicit-fallthrough -Wno-class-memaccess -Wno-redundant-move
-Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor
-Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wc
tad-maybe-unsupported -fdiagnostics-color -fdata-sections  -std=c++20
-fdiagnostics-color=always -nostdinc++ -Werror=return-type -W -Wall
-Wchar-subscripts -Wconversion -Wmismatched-tags -Wmissing-braces -Wun
used-function -Wshadow -Wsign-compare -Wsign-conversion -Wstrict-aliasing=2
-Wstrict-overflow=4 -Wunused-parameter -Wunused-variable -Wwrite-strings
-Wundef -Wno-suggest-override -Wno-error -pedantic -fstrict
-aliasing -D_DEBUG -MD -MT
libcxxabi/src/CMakeFiles/cxxabi_static_objects.dir/cxa_demangle.cpp.o -MF
libcxxabi/src/CMakeFiles/cxxabi_static_objects.dir/cxa_demangle.cpp.o.d -o
libcxxabi/src/CMakeFiles/cxxabi_
static_objects.dir/cxa_demangle.cpp.o -c
/var/tmp/portage/sys-libs/libcxxabi-16.0.6/work/libcxxabi/src/cxa_demangle.cpp
/var/tmp/portage/sys-libs/libcxxabi-16.0.6/work/libcxxabi/src/cxa_demangle.cpp:407:1:
internal compiler error: in comptypes, at cp/typeck.cc:1681
  407 | }  // __cxxabiv1
  | ^
0x559308a2e393 comptypes(tree_node*, tree_node*, int)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/cp/typeck.cc:1681
0x55930a7f6476 unify
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/cp/pt.cc:24956
0x55930a7f60ad unify
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/cp/pt.cc:25009
0x55930a7f4ed6 get_partial_spec_bindings
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/cp/pt.cc:25893
0x55930a8755f0 most_specialized_partial_spec(tree_node*, int, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/cp/pt.cc:26190
0x5593098ca8f3 specialization_of
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/cp/parser.cc:34994
0x5593098ca8f3 class_decl_loc_t::diag_mismatched_tags(tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/cp/parser.cc:35178
0x559308abbd61 class_decl_loc_t::diag_mismatched_tags()
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/cp/parser.cc:35320
0x55930ac85c1c c_parse_file()
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/cp/parser.cc:51175
0x55930ac564e3 c_common_parse_file()
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/c-family/c-opts.cc:1301
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.
```

```
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python
--enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ 

[Bug target/113641] New: 510.parest_r with PGO at O2 slower than GCC 12 (7% on Zen 3&2, 4% on CascadeLake) since r13-4272-g8caf155a3d6e23

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

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

Bug ID: 113641
   Summary: 510.parest_r with PGO at O2 slower than GCC 12 (7% on
Zen 3&2, 4% on CascadeLake) since
r13-4272-g8caf155a3d6e23
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu

During the development of GCC 13, 510.parest_r run-time regressed on x86_64
when built with profile guided optimization and just plain O2 and master than
when using GCC12.  The difference is not big but fairly clear cut, about 7.6%
on Zen3:

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=740.457.0=892.457.0=694.457.0;

and about 7.2% on Zen2:

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=777.457.0=932.457.0=687.457.0;

The graphs above show use of both LTO and PGO but LTO is not necessary.

I was able to bisect the regression to commit r13-4272-g8caf155a3d6e23 (i386:
Only enable small loop unrolling in backend [PR 107692]).  parest_r is also
about 4% slower when compiled with this revision than with the previous one on
Intel CascadeLake.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug debug/8188] DW_AT_containing_type incorrectly emitted

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

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

--- Comment #6 from Tom Tromey  ---
I wanted to mention -- I don't particularly care if this
attribute goes away or not (assuming it indeed doesn't
negatively affect gdb), but I do dispute the idea that
DWARF proscribes which attributes may or may not appear.
DWARF itself claims to be lenient in the text.
Extensions like this are, and should be, commonplace;
and readers ought to ignore attributes they do not understand.

[Bug debug/8188] DW_AT_containing_type incorrectly emitted

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

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

--- Comment #5 from Tom Tromey  ---
The uses in gdb seem to all be for the old v2 C++ ABI.
Removing them might break that code, but OTOH that code
is untested, probably already broken, and anyway long
since obsolete.

Note that Rust+LLVM use this attribute as an extension,
to associate a vtable with a concrete type.  This is
what lets trait objects work in gdb.  There was a thread
on the GCC list (IIRC) about doing something similar
for C++; however, I can't find the thread now.

[Bug other/113336] [14 Regression] libatomic (testsuite) regressions on arm

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com
   Target Milestone|--- |14.0

--- Comment #7 from Roger Sayle  ---
A revised patch has been posted for review/approval to gcc-patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644147.html

[Bug c++/110075] Bogus -Wdangling-reference

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

--- Comment #6 from Viktor Ostashevskyi  ---
(In reply to Marek Polacek from comment #5)
> Yes, because we'd have to analyze the body of the function to see that it
> does not return one of the parameters, which often we can't do.
> 
> There will be an attribute soon to suppress that warning.

I'm wondering whether this diagnostics should be in -Wall or -Wextra at all.
It is assumed that diagnostics in -Wall or -Wextra generally "works".

Here, diagnostics clearly fails on simplest case and I don't think marking huge
codebase with some attribute is a proper solution...

[Bug c++/113640] 'deducing this' lambda invoked multiple times unexpectedly

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
Noted that changing `this auto self` to `this auto&& self` will get the
expected results

[Bug c++/113640] New: 'deducing this' lambda invoked multiple times unexpectedly

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 113640
   Summary: 'deducing this' lambda invoked multiple times
unexpectedly
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

#include 

int main() {
  auto l = [](this auto self, int n) {
std::cout << n << " ";
return self;
  };
  l(1)(42)(100);
}

https://godbolt.org/z/3rEoGsPWe

Clang prints "1 42 100" as expected, however, GCC prints "1 1 42 1 42 100",
which is weird.

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

[zsojka at seznam dot cz via Gcc-bugs]

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

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

Created attachment 57245
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57245=edit
reduced testcase (from gcc.dg/torture/pr57393-1.c)

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c 
during GIMPLE pass: bitintlower
testcase.c: In function 'foo':
testcase.c:10:1: internal compiler error: in handle_operand_addr, at
gimple-lower-bitint.cc:2265
   10 | foo (struct S s)
  | ^~~
0xd84efa handle_operand_addr
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2265
0x2738496 handle_operand_addr
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2170
0x273878f lower_muldiv_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:3400
0x274b423 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6562
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8474-20240128132141-g46df13697a4-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--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-8474-20240128132141-g46df13697a4-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240128 (experimental) (GCC)

[Bug c++/113638] Array bounds of variable templates are not correctly deduced from initializers since GCC13

[de34 at live dot cn via Gcc-bugs]

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

--- Comment #1 from Jiang An  ---
> The following code snippet is incorrectly processed since C++13.

Typo: this should be "since GCC13".

[Bug c++/113638] New: Array bounds of variable templates are not correctly deduced from initializers since GCC13

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 113638
   Summary: Array bounds of variable templates are not correctly
deduced from initializers since GCC13
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Keywords: accepts-invalid, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

The following code snippet is incorrectly processed since C++13.

Godbolt link: https://godbolt.org/z/xjEqnqodj

```
#include 

template
constexpr int my_array[]{Is...};

static_assert(std::is_same_v), const int[5]>);
// rejected since GCC13
static_assert(sizeof(my_array<1, 2, 3, 4, 5>) == sizeof(int) * 5); // rejected
since GCC13

static_assert(std::is_same_v), const int[]>);
// passes since GCC13, but should not
```

It seems that GCC gives up deducing the array bounds from initializers of
variable templates since GCC13.

[Bug target/112864] [14 regression] Many libphobos tests FAIL on macOS 12+

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-28
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-January
   ||/644143.html

--- Comment #1 from Iain Sandoe  ---
patch : https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644143.html

[Bug target/112863] [14 regression] Many obj-c++ tests FAIL on macOS 14

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

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

Iain Sandoe  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-January
   ||/644142.html

--- Comment #6 from Iain Sandoe  ---
patch posted https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644142.html

the subsequent exposed fails should already be fixed by:
https://gcc.gnu.org/pipermail/gcc-cvs/2024-January/397901.html (duplicate libs)
https://gcc.gnu.org/pipermail/gcc-cvs/2024-January/397902.html (segvs because
of over aligned meta-data).

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

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

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

Iain Sandoe  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-January
   ||/644141.html

--- Comment #12 from Iain Sandoe  ---
patch posted ;
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644141.html

[Bug target/112861] [14 regression] Most gdc tests FAIL on macOS 12+

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

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

Iain Sandoe  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-January
   ||/644140.html

--- Comment #3 from Iain Sandoe  ---
patch posted ;
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644140.html

[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267

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

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

--- Comment #15 from Oleg Endo  ---
(In reply to Roger Sayle from comment #14)
> My apologies for not keeping folks updated on my thinking. Following Oleg's
> feedback, I've decided to slim down my proposed fix to the bare minimum, and
> postpone the other rtx_costs improvements until GCC 15 (or later), when I'll
> have more time to use to CSiBE to demonstrate the benefits/tradeoffs for -Os
> and -Oz.

Alright, I think we've got a couple of issues here.  It's a good idea to split
out and address the actual issue of this PR.  I'm curious to see the effects of
-Oz.


> For example, with fwprop about to transition to insn_cost, it
> would be good for the SH backend to provide a sh_insn_cost target hook.

Nothing against that.  I just really wanted to understand your line of thought
of altering the address costs (i.e. treating all addressing modes with equal
cost 0) in case of optimizing for size.

> 
> The current minimal patch to fix this specific regression is:
> 
> diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
> index 2c411c3..fba6c0fd465 100644
> --- a/gcc/config/sh/sh.cc
> +++ b/gcc/config/sh/sh.cc
> @@ -3313,7 +3313,8 @@ sh_rtx_costs (rtx x, machine_mode mode
> ATTRIBUTE_UNUSED, i
> nt outer_code,
> {
>   *total = sh_address_cost (XEXP (XEXP (x, 0), 0),
> GET_MODE (XEXP (x, 0)),
> -   MEM_ADDR_SPACE (XEXP (x, 0)), true);
> +   MEM_ADDR_SPACE (XEXP (x, 0)), true)
> +  + COSTS_N_INSNS (1);
>   return true;
> }
>return false;
> 
> The minor complication is that as explained above this results in:
> PASS->FAIL: gcc.target/sh/pr59533-1.c scan-assembler-times addc 6
> PASS->FAIL: gcc.target/sh/pr59533-1.c scan-assembler-times cmp/pz 25
> PASS->FAIL: gcc.target/sh/pr59533-1.c scan-assembler-times shll 3
> PASS->FAIL: gcc.target/sh/pr59533-1.c scan-assembler-times subc 14
> 
> which were failures that were fixed (or silenced) by my solution to PR111267.

Yeah, I can imagine that the correction to mem-sign-extend costs will pop
something else.  It should be adapted of course as well.  I'll try to check
that out myself. Although it might take (a bit overloaded at the moment).


> I will note that although the scan-assembler-times complain, that this
> tweak to sh_rtx_costs reduces the total number of instructions in pr59533-1.c
> which (normally) indicates that its an improvement.
> 
> *** old.s   Thu Jan 25 22:54:11 2024
> --- new.s   Thu Jan 25 22:54:23 2024
> ***
> *** 15,23 
> .global test_01
> .type   test_01, @function
>   test_01:
> -   mov.b   @r4,r0
> -   extu.b  r0,r0
> mov.b   @r4,r1
> cmp/pz  r1
> mov #0,r1
> rts
> --- 15,22 
> .global test_01
> .type   test_01, @function
>   test_01:
> mov.b   @r4,r1
> +   extu.b  r1,r0
> cmp/pz  r1
> mov #0,r1
> rts
> ...

Which test is that exactly?  In pr59533-1.c 'test_01' is this:

int
test_01 (unsigned char* a)
{
  /* 1x cmp/pz, 1x addc  */
  return a[0] + (a[0] < 128);
}

... which is totally different from what you posted above.  Something seems to
got mixed up.



> Hence I'm looking into PR59533, which has separate tests for sh2a and !sh2a,
> and my latest discoveries are the -m2a isn't supported if I build gcc using
> --target=sh3-linux-gnu, and that --target=sh2a-linux-gnu doesn't
> automatically default to --target=sh2aeb-linux-gnu and instead gives a fatal
> error about "SH2A does not support little-endian" during the build.  All
> part (joy?) of the learning curve.

Yeah, every backend has its own flavor of setup and dealing with options.
You don't need to build for linux-gnu to check these issues or even run the
CSiBE set. Just configure the build it for --target=sh-elf and it should be
good to go.  By default it builds all multilibs and the default option is -m1
(= SH1).  You can then use -m2a -mb for SH2A.

[Bug debug/113637] New: ICE: in as_a, at machmode.h:381 with extern function declaration and _BitInt() used as VLA size

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113637
   Summary: ICE: in as_a, at machmode.h:381 with extern function
declaration and _BitInt() used as VLA size
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57244
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57244=edit
reduced testcase (from gcc.dg/Wvla-parameter-4.c)

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c -g
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: in as_a, at machmode.h:381
5 | }
  | ^
0x7418a8 scalar_int_mode as_a(machine_mode)
/repo/gcc-trunk/gcc/machmode.h:381
0x748787 scalar_int_mode as_a(machine_mode)
/repo/gcc-trunk/gcc/tree.h:3813
0x748787 loc_list_from_tree_1
/repo/gcc-trunk/gcc/dwarf2out.cc:19030
0x1058d7b loc_list_from_tree_1
/repo/gcc-trunk/gcc/dwarf2out.cc:19443
0x1066138 loc_list_from_tree
/repo/gcc-trunk/gcc/dwarf2out.cc:19737
0x1066138 add_scalar_info
/repo/gcc-trunk/gcc/dwarf2out.cc:21528
0x10671e1 add_subscript_info
/repo/gcc-trunk/gcc/dwarf2out.cc:21767
0x1053f12 gen_array_type_die
/repo/gcc-trunk/gcc/dwarf2out.cc:22641
0x1053f12 gen_type_die_with_usage
/repo/gcc-trunk/gcc/dwarf2out.cc:26433
0x10557fd gen_type_die
/repo/gcc-trunk/gcc/dwarf2out.cc:26496
0x10557fd modified_type_die
/repo/gcc-trunk/gcc/dwarf2out.cc:13924
0x1055dc5 modified_type_die
/repo/gcc-trunk/gcc/dwarf2out.cc:14068
0x10577a6 add_type_attribute
/repo/gcc-trunk/gcc/dwarf2out.cc:22387
0x1068fc1 gen_formal_parameter_die
/repo/gcc-trunk/gcc/dwarf2out.cc:23096
0x10693ce gen_formal_types_die
/repo/gcc-trunk/gcc/dwarf2out.cc:23191
0x104ce8b gen_subprogram_die
/repo/gcc-trunk/gcc/dwarf2out.cc:24063
0x10508ca gen_decl_die
/repo/gcc-trunk/gcc/dwarf2out.cc:27113
0x106e6cf decls_for_scope
/repo/gcc-trunk/gcc/dwarf2out.cc:26676
0x104beee gen_subprogram_die
/repo/gcc-trunk/gcc/dwarf2out.cc:24174
0x10508ca gen_decl_die
/repo/gcc-trunk/gcc/dwarf2out.cc:27113
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8474-20240128132141-g46df13697a4-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--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-8474-20240128132141-g46df13697a4-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240128 (experimental) (GCC)

[Bug middle-end/113636] New: internal compiler error: in dead_debug_global_find, at valtrack.cc:275

[toon at moene dot org via Gcc-bugs]

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

Bug ID: 113636
   Summary: internal compiler error: in dead_debug_global_find, at
valtrack.cc:275
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: toon at moene dot org
  Target Milestone: ---

A build + test run [r14-8465] on aarch64-linux-gnu draws the following ICE
while compiling math/cmplx:

during RTL pass: sched1
cmath_test.go: In function 'math/cmplx.BenchmarkCos':
cmath_test.go:1520:1: internal compiler error: in dead_debug_global_find, at
valtrack.cc:275
 1520 | func BenchmarkCos(b *testing.B) {
  | ^
0x131ce17 dead_debug_global_find
/home/toon/compilers/gcc/gcc/valtrack.cc:275
0x131ce17 dead_debug_global_find
/home/toon/compilers/gcc/gcc/valtrack.cc:269
0x131cef3 dead_debug_global_replace_temp
/home/toon/compilers/gcc/gcc/valtrack.cc:321
0x131df33 dead_debug_promote_uses
/home/toon/compilers/gcc/gcc/valtrack.cc:450
0x131df33 dead_debug_local_finish(dead_debug_local*, bitmap_head*)
/home/toon/compilers/gcc/gcc/valtrack.cc:487
0x1d777eb dce_process_block
/home/toon/compilers/gcc/gcc/dce.cc:1060
0x1d777eb fast_dce
/home/toon/compilers/gcc/gcc/dce.cc:1128
0x1d77d17 rest_of_handle_fast_dce
/home/toon/compilers/gcc/gcc/dce.cc:1194
0x1d77d17 run_fast_df_dce()
/home/toon/compilers/gcc/gcc/dce.cc:1242
0xa6c8e7 df_lr_finalize
/home/toon/compilers/gcc/gcc/df-problems.cc:1065
0xa6585f df_analyze_problem(dataflow*, bitmap_head*, int*, int)
/home/toon/compilers/gcc/gcc/df-core.cc:1190
0xa658ff df_analyze_1
/home/toon/compilers/gcc/gcc/df-core.cc:1235
0x1e5574b sched_init()
/home/toon/compilers/gcc/gcc/haifa-sched.cc:7348
0x1e570e7 haifa_sched_init()
/home/toon/compilers/gcc/gcc/haifa-sched.cc:7372
0xf38a4f schedule_insns()
/home/toon/compilers/gcc/gcc/sched-rgn.cc:3517
0xf39157 schedule_insns()
/home/toon/compilers/gcc/gcc/sched-rgn.cc:3511
0xf39157 rest_of_handle_sched
/home/toon/compilers/gcc/gcc/sched-rgn.cc:3729
0xf39157 execute
/home/toon/compilers/gcc/gcc/sched-rgn.cc:3839
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.
FAIL: math/cmplx

The build was started with the following system compiler:

$ echo | gcc -### -E - -march=native -mtune=native
Using built-in specs.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 13.2.0-9'
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--enable-fix-cortex-a53-843419 --disable-werror
--enable-offload-targets=nvptx-none=/build/reproducible-path/gcc-13-13.2.0/debian/tmp-nvptx/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=4
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Debian 13.2.0-9) 
COLLECT_GCC_OPTIONS='-E'   '-mlittle-endian' '-mabi=lp64' '-mtune=thunderxt88'
 /usr/libexec/gcc/aarch64-linux-gnu/13/cc1 -E -quiet -imultiarch
aarch64-linux-gnu - -mlittle-endian "-mabi=lp64" "-mtune=thunderxt88"
-fasynchronous-unwind-tables -dumpbase -
COMPILER_PATH=/usr/libexec/gcc/aarch64-linux-gnu/13/:/usr/libexec/gcc/aarch64-linux-gnu/13/:/usr/libexec/gcc/aarch64-linux-gnu/:/usr/lib/gcc/aarch64-linux-gnu/13/:/usr/lib/gcc/aarch64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/aarch64-linux-gnu/13/:/usr/lib/gcc/aarch64-linux-gnu/13/../../../aarch64-linux-gnu/:/usr/lib/gcc/aarch64-linux-gnu/13/../../../../lib/:/lib/aarch64-linux-gnu/:/lib/../lib/:/usr/lib/aarch64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/aarch64-linux-gnu/13/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-E'   '-mlittle-endian' '-mabi=lp64' '-mtune=thunderxt88'

using these configure flags:

Compiler version: 14.0.1 20240127 (experimental) [master r14-8465-g5200ef26ac1]
(GCC) 

Re: _BitInt() as underlying enum type

[Jakub Jelinek via Gcc-bugs]

On Sat, Jan 27, 2024 at 08:25:04PM -0800, Andrew Pinski via Gcc-bugs wrote:
> Just an FYI, the clang issue was
> https://github.com/llvm/llvm-project/issues/69619 .
> With the following commit to the LLVM git repo as the fix:
> https://github.com/llvm/llvm-project/commit/5175cd777c57190ab9860c304796d386e4df9b8f

Indeed, the C23 draft I have specifies in 6.7.2.2/5:
"If an enum type specifier is present, then the longest possible sequence of 
tokens that can be
interpreted as a specifier qualifier list is interpreted as part of the enum 
type specifier. It shall name
an integer type that is neither an enumeration nor a bit-precise integer
type."

Jakub

[Bug target/113635] [14 Regression] libatomic has undefined reference to libat_test_and_set_1_i2 in libatomic on arm-linux-gnueabi

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

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #1 from Matthias Klose  ---
see PR113336

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

[Bug other/113336] [14 Regression] libatomic (testsuite) regressions on arm

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

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

--- Comment #6 from Matthias Klose  ---
*** Bug 113635 has been marked as a duplicate of this bug. ***

[Bug other/113336] libatomic (testsuite) regressions on arm

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

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #5 from Matthias Klose  ---
see also PR113336, causes also build failure of gnat and libgo on
arm-linux-gnueabi

[Bug target/113635] New: [14 Regression] libatomic has undefined reference to libat_test_and_set_1_i2 in libatomic on arm-linux-gnueabi

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

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

Bug ID: 113635
   Summary: [14 Regression] libatomic has undefined reference to
libat_test_and_set_1_i2 in libatomic on
arm-linux-gnueabi
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with trunk 20240127 (and earlier snapshots) on arm-linux-gnueabi,
configured with 

 --with-arch=armv5te
 --with-float=soft

This error is from a gcc-13 build, with the libatomic installed from a gcc-14
build, but also seen when enabling Ada or go in a trunk build:

/usr/bin/ld: /lib/arm-linux-gnueabi/libatomic.so.1: undefined reference to
`libat_test_and_set_1_i2'
collect2: error: ld returned 1 exit status
arm-linux-gnueabi-gnatlink-12: error when calling
/usr/bin/arm-linux-gnueabi-gcc-12
gnatmake: *** link failed.

The same thing also lets the build fail later in libgo.

$ objdump -T /usr/lib/arm-linux-gnueabi/libatomic.so.1|grep libat_
  D  *UND*    Baselibat_test_and_set_1_i2

the libatomic from a GCC 13 build doesn't show this undefined symbol.

[Bug libgcc/113402] Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc_s.so.1

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:837827f8f2542c36ba5944b4da0a76ea6a64b08b

commit r14-8476-g837827f8f2542c36ba5944b4da0a76ea6a64b08b
Author: Iain Sandoe 
Date:   Tue Jan 16 10:21:14 2024 +

Fix __builtin_nested_func_ptr_{created,deleted} symbol versions [PR113402]

The symbols for the functions supporting heap-based trampolines were
exported at an incorrect symbol version, the following patch fixes that.

As requested in the PR, this also renames __builtin_nested_func_ptr* to
__gcc_nested_func_ptr*.  In carrying our the rename, we move the builtins
to use DEF_EXT_LIB_BUILTIN.

PR libgcc/113402

gcc/ChangeLog:

* builtins.cc (expand_builtin): Handle
BUILT_IN_GCC_NESTED_PTR_CREATED
and BUILT_IN_GCC_NESTED_PTR_DELETED.
* builtins.def (BUILT_IN_GCC_NESTED_PTR_CREATED,
BUILT_IN_GCC_NESTED_PTR_DELETED): Make these builtins LIB-EXT and
rename the library fallbacks to __gcc_nested_func_ptr_created and
__gcc_nested_func_ptr_deleted.
* doc/invoke.texi: Rename these to __gcc_nested_func_ptr_created
and __gcc_nested_func_ptr_deleted.
* tree-nested.cc (finalize_nesting_tree_1): Use builtin_explicit
for
BUILT_IN_GCC_NESTED_PTR_CREATED and
BUILT_IN_GCC_NESTED_PTR_DELETED.
* tree.cc (build_common_builtin_nodes): Build the
BUILT_IN_GCC_NESTED_PTR_CREATED and BUILT_IN_GCC_NESTED_PTR_DELETED
local
builtins only for non-explicit.

libgcc/ChangeLog:

* config/aarch64/heap-trampoline.c: Rename
__builtin_nested_func_ptr_created to __gcc_nested_func_ptr_created
and
__builtin_nested_func_ptr_deleted to __gcc_nested_func_ptr_deleted.
* config/i386/heap-trampoline.c: Likewise.
* libgcc2.h: Likewise.
* libgcc-std.ver.in (GCC_7.0.0): Likewise and then move
__gcc_nested_func_ptr_created and
__gcc_nested_func_ptr_deleted from this symbol version to ...
(GCC_14.0.0): ... this one.

Signed-off-by: Iain Sandoe 
Co-authored-by: Jakub Jelinek  

[Bug target/113560] Strange code generated when optimizing a multiplication on x86_64

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com

--- Comment #7 from Roger Sayle  ---
I'm bootstrapping and regression testing a patch.

[Bug c/113438] ICE (segfault) in dwarf2out_decl with -g -std=c23 on c23-tag-composite-2.c

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #5 from Martin Uecker  ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644124.html

[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #2 from nightstrike  ---
(In reply to GCC Commits from comment #1)
> * gcc.dg/analyzer/null-deref-pr105755.c: Likewise.

In this test, the XLI function tries to store a pointer in a long.  That type
should be __UINTPTR_TYPE__ instead; we see warnings on any LLP64 system.

[Bug analyzer/109577] -Wanalyzer-allocation-size mishandles __builtin_mul_overflow

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #5 from nightstrike  ---
(In reply to David Malcolm from comment #4)
> Thanks for fixing this Tim.
> 
> Keeping open to track backporting this to the gcc 13 branch.

Before this gets backported, the testcase should be fixed.  It uses an
incorrect declaration of malloc, assuming that size_t is long.  The standard
defines malloc as size_t, so the declaration should use __SIZE_TYPE__ instead. 
This works, although you could also just include stdlib.h or use
__builtin_malloc.

[Bug analyzer/110014] -Wanalyzer-allocation-size mishandles realloc (..., .... * sizeof (object))

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #3 from nightstrike  ---
(In reply to David Malcolm from comment #2)
> Thanks for fixing this Tim.
> 
> Keeping open to track backporting this to the gcc 13 branch.

Before this gets backported, the testcase should be fixed.  It uses an
incorrect declaration of realloc, assuming that size_t is long.  The standard
defines realloc as size_t, so the declaration should use __SIZE_TYPE__ instead.
 This works, although you could also just include stdlib.h or use
__builtin_realloc.