[Bug libstdc++/114085] New: Internal (cross) compiler error when building libstdc++ for the H8/300 family
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114085
Bug ID: 114085
Summary: Internal (cross) compiler error when building
libstdc++ for the H8/300 family
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jdx at o2 dot pl
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: h8300-elf
Created attachment 57519
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57519&action=edit
Preprocessed libstdc++-v3/src/c++11/cxx11-locale-inst.cc
I get the following error when I try to build rev. 98702303:
[...]
make[5]: Leaving directory
'/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/src/c++98'
Making all in c++11
make[5]: Entering directory
'/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/src/c++11'
[...]
/bin/bash ../../libtool --tag CXX --tag disable-shared --mode=compile
/home/jdx/testgcc/builddir/./gcc/xgcc -shared-libgcc
-B/home/jdx/testgcc/builddir/./gcc -nostdinc++
-L/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/src
-L/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/src/.libs
-L/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/libsupc++/.libs -nostdinc
-B/home/jdx/testgcc/builddir/h8300-elf/newlib/ -isystem
/home/jdx/testgcc/builddir/h8300-elf/newlib/targ-include -isystem
/home/jdx/testgcc/combosrc/newlib/libc/include
-B/home/jdx/testgcc/installdir/h8300-elf/bin/
-B/home/jdx/testgcc/installdir/h8300-elf/lib/ -isystem
/home/jdx/testgcc/installdir/h8300-elf/include -isystem
/home/jdx/testgcc/installdir/h8300-elf/sys-include
-L/home/jdx/testgcc/builddir/./ld
-I/home/jdx/testgcc/combosrc/libstdc++-v3/../libgcc
-I/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/h8300-elf
-I/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include
-I/home/jdx/testgcc/combosrc/libstdc++-v3/libsupc++ -std=gnu++11
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=cxx11-locale-inst.lo -g -O2 -c -o cxx11-locale-inst.lo
../../../../../combosrc/libstdc++-v3/src/c++11/cxx11-locale-inst.cc
libtool: compile: /home/jdx/testgcc/builddir/./gcc/xgcc -shared-libgcc
-B/home/jdx/testgcc/builddir/./gcc -nostdinc++
-L/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/src
-L/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/src/.libs
-L/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/libsupc++/.libs -nostdinc
-B/home/jdx/testgcc/builddir/h8300-elf/newlib/ -isystem
/home/jdx/testgcc/builddir/h8300-elf/newlib/targ-include -isystem
/home/jdx/testgcc/combosrc/newlib/libc/include
-B/home/jdx/testgcc/installdir/h8300-elf/bin/
-B/home/jdx/testgcc/installdir/h8300-elf/lib/ -isystem
/home/jdx/testgcc/installdir/h8300-elf/include -isystem
/home/jdx/testgcc/installdir/h8300-elf/sys-include
-L/home/jdx/testgcc/builddir/./ld
-I/home/jdx/testgcc/combosrc/libstdc++-v3/../libgcc
-I/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/h8300-elf
-I/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include
-I/home/jdx/testgcc/combosrc/libstdc++-v3/libsupc++ -std=gnu++11
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=cxx11-locale-inst.lo -g -O2 -c
../../../../../combosrc/libstdc++-v3/src/c++11/cxx11-locale-inst.cc -o
cxx11-locale-inst.o
In file included from
/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/bits/locale_facets_nonio.h:2069,
from
/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/locale:43,
from
../../../../../combosrc/libstdc++-v3/src/c++11/locale-inst.cc:38,
from
../../../../../combosrc/libstdc++-v3/src/c++11/cxx11-locale-inst.cc:37:
/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/bits/locale_facets_nonio.tcc:
In member function '_InIter std::__cxx11::money_get<_CharT,
_InIter>::_M_extract(iter_type, iter_type, std::ios_base&,
std::ios_base::iostate&, std::string&) const [with bool _Intl = true; _CharT =
char; _InIter = std::istreambuf_iterator >]':
/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/bits/locale_facets_nonio.tcc:350:7:
error: unable to generate reloads for:
350 | }
| ^
(insn 1414 10225 9370 143 (set (mem/c:QI (plus:SI (reg/f:SI 11 fp)
(const_int -157 [0xff63])) [112 %sfp+-157 S1 A8])
(xor:QI (mem/c:QI (plus:SI (reg/f:SI 11 fp)
(const_int -157 [0xff63])) [112 %sfp+-157 S1
A8])
(const_int 1 [0x1])))
"/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/bits/locale_facets_nonio.tcc":207:12
discrim 2 358 {xorqi3_1}
(nil))
during RTL pass: reload
/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/bits/locale_facets_nonio.tcc:350:7:
internal com
[Bug middle-end/114084] ICE: SIGSEGV: infinite recursion in fold_build2_loc / fold_binary_loc with _BitInt(127)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114084
--- Comment #2 from Andrew Pinski ---
Here is another testcase, the only use of _BitInt is in the cast, everything
else is a bitfield:
```
struct a
{
unsigned t:(sizeof(int)*8-1);
};
typedef unsigned _BitInt(sizeof(int)*8-1) ub31;
struct a ub63_0;
struct a ub63_1;
void
foo (void)
{
ub63_1.t = (ub31)
((ub63_0.t | (-1u>>1) ) >> 1 | (ub63_0.t | 1u) << 4);
}
```
I still can't figure out why the cast is needed though.
[Bug sanitizer/114037] ASAN fork should ensure no unwind is in progress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114037 Xi Ruoyao changed: What|Removed |Added Status|UNCONFIRMED |WAITING CC||xry111 at gcc dot gnu.org Last reconfirmed||2024-02-24 Ever confirmed|0 |1 --- Comment #1 from Xi Ruoyao --- IIUC this is an issue in libasan, not the compiler. libasan is imported from LLVM and you should report it to LLVM developers first.
[Bug middle-end/114084] ICE: SIGSEGV: infinite recursion in fold_build2_loc / fold_binary_loc with _BitInt(127)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114084
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-02-24
--- Comment #1 from Andrew Pinski ---
Confirmed, here is a testcase which should be generic for even 16bit int
targets.
```
typedef unsigned _BitInt(sizeof(int)*8-1) ub63;
ub63 ub63_0, ub63_1;
void
foo (void)
{
ub63_1 = (ub63)
((ub63_0 | (-1u>>1) ) >> 1 | (ub63_0 | 5) << 4);
}
```
Note I tried to reproduce this using bitfields but that works. Also note the
cast is important here ...
[Bug rtl-optimization/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 Andreas Krebbel changed: What|Removed |Added CC||stefansf at linux dot ibm.com --- Comment #4 from Andreas Krebbel --- Hi Segher, any guidance on how to proceed with that? This recently was brought up by distro people again because it is causing actual problems in their build setups.
[Bug tree-optimization/114084] New: ICE: SIGSEGV: infinite recursion in fold_build2_loc / fold_binary_loc with _BitInt(127)
14-9151-20240223113818-g22121546e03-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240223 (experimental) (GCC)
[Bug rtl-optimization/114054] ICE: in reduce_to_bit_field_precision, at expr.cc:12658 with -Og -fwhole-program -fno-tree-ccp -fprofile-use -fno-tree-copy-prop and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114054 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug modula2/113749] [14 Regression] m2 enabled build times out on i686-gnu (GNU Hurd)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749 Gaius Mulley changed: What|Removed |Added Attachment #57516|0 |1 is obsolete|| --- Comment #5 from Gaius Mulley --- Created attachment 57517 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57517&action=edit Proposed fix v2 Correction - to include wrapc.o when linking the pge tool.
[Bug analyzer/111289] [13 Regression] Unwarranted -Wanalyzer-va-arg-type-mismatch warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289
John David Anglin changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Comment #4 from John David Anglin ---
On hppa64-hp-hpux11.11:
FAIL: c-c++-common/analyzer/stdarg-pr111289-int.c -std=c++98 (test for
warnings, line 60)
FAIL: c-c++-common/analyzer/stdarg-pr111289-int.c -std=c++98 (test for excess
errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/analyzer/stdarg-pr111289-int.c:5:22:
error: conflicting declaration 'typedef unsigned int mode_t'
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/analyzer/stdarg-pr111289-int.c:17:30:
warning: 'mode_t' {aka 'short unsigned int'} is promoted to 'int' when passed
through '...'
[Bug target/103433] ICE in convert_move, at expr.c:219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103433 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/82859 --- Comment #4 from Andrew Pinski --- Note LLVM also ICEs with similar testcase: https://github.com/llvm/llvm-project/issues/82859
[Bug middle-end/114069] Type punning RISC-V and SVE vectors causes ICE at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114069 Andrew Pinski changed: What|Removed |Added Depends on||103433 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103433 --- Comment #3 from Andrew Pinski --- Oh the SVE issue was already filed as PR 103433 but I think this is the same. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103433 [Bug 103433] ICE in convert_move, at expr.c:219
[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499
--- Comment #6 from Jerry DeLisle ---
This is an interesting puzzle. I took the -fdump-tree-original output of
compiling the test case and edited out all except the initialization of the two
variables char1 and char2.
I lined these up so we could see what each 4-byte character looks like. The
last two characters should be two characters of c383. We are generating c300
8300 for each character.
---
__builtin_memmove ((void *) &char1, (void *) &"
T\x00\x00\x00
e\x00\x00\x00
s\x00\x00\x00
t\x00\x00\x00
\x00\x00\x00
w\x00\x00\x00
i\x00\x00\x00
t\x00\x00\x00
h\x00\x00\x00
o\x00\x00\x00
u\x00\x00\x00
t\x00\x00\x00
\x00\x00\x00
l\x00\x00\x00
o\x00\x00\x00
c\x00\x00\x00
a\x00\x00\x00
l\x00\x00\x00
\x00\x00\x00
c\x00\x00\x00
h\x00\x00\x00
a\x00\x00\x00
r\x00\x00"[1]{lb: 1 sz: 4}, 92);
__builtin_memmove ((void *) &char2, (void *) &"
T\x00\x00\x00
e\x00\x00\x00
s\x00\x00\x00
t\x00\x00\x00
\x00\x00\x00
w\x00\x00\x00
i\x00\x00\x00
t\x00\x00\x00
h\x00\x00\x00
\x00\x00\x00
l\x00\x00\x00
o\x00\x00\x00
c\x00\x00\x00
a\x00\x00\x00
l\x00\x00\x00
\x00\x00\x00
c\x00\x00\x00
h\x00\x00\x00
a\x00\x00\x00
r\x00\x00\x00
\x00\x00\x00
\xc3\x00\x00\x00
\x83\x00\x00\x00
\xc3\x00\x00\x00
\x83\x00\x00"[1]{lb: 1 sz: 4}, 100);
[Bug target/112375] [14 Regression] vget_set_lane_1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112375 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug middle-end/114069] Type punning RISC-V and SVE vectors causes ICE at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114069 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/82859 --- Comment #2 from Andrew Pinski --- Note clang crashes also on the SVE case but not the RISCV issue. Filed https://github.com/llvm/llvm-project/issues/82859 for the SVE issue. Note GCC is crashing in general code for both really.
[Bug middle-end/114069] Type punning RISC-V and SVE vectors causes ICE at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114069
Andrew Pinski changed:
What|Removed |Added
Summary|Type punning RISC-V vectors |Type punning RISC-V and SVE
|causes ICE at -O1 |vectors causes ICE at -O1
Last reconfirmed||2024-02-24
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Target|riscv |riscv aarch64
Component|target |middle-end
--- Comment #1 from Andrew Pinski ---
Confirmed.
This is not only a RISCV issue but also happens with aarch64's SVE types too:
```
#include
svint8_t f(svuint8x2_t s) {
return *reinterpret_cast(&s);
}
```
[Bug driver/114082] Guidelines for options are empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082 Andrew Pinski changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- It was added in r9-3547-g92646d25778952 .
[Bug driver/114082] Guidelines for options are empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-02-24 Status|UNCONFIRMED |NEW Keywords||FIXME --- Comment #2 from Andrew Pinski --- No it is empty in ux.texi: ``` @node Guidelines for Options @section Guidelines for Options @cindex command-line options, guidelines for @cindex options, guidelines for @cindex guidelines for options @c TODO ```
[Bug modula2/113749] [14 Regression] m2 enabled build times out on i686-gnu (GNU Hurd)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749 --- Comment #4 from Gaius Mulley --- Created attachment 57516 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57516&action=edit Proposed fix Here is a proposed patch. The bug fix changes the FIO module to use the target O_RDONLY, O_WRONLY, SEEK_SET and SEEK_END (now available from the module wrapc). I've rebuilt the bootstrap tools mc and pge as they have their own wrapc and C translations of FIO.
[Bug target/114083] Possible word play on conditional/unconditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083 --- Comment #4 from Maciej W. Rozycki --- The flag enables the use of the conditional-move operations even with hardware that has no support for such operations, hence unconditionally. Such operations, where unavailable, are then synthesized as sequences of instructions from other operations, avoiding the use of branches where they'd turn out more costly according to the `-mbranch-cost=' setting (either specified or inferred from the `-mtune=' setting in effect). Normally the compiler only enables conditional-move operations where directly provided by hardware, according to the `-march=' or `-mcpu=' options used for compilation (either specified or defaulted). The help line is too short to provide a more elaborate explanation and merely serves as a quick reminder saving one from reaching for the manual. I hope this is good enough for this purpose, but if someone has a better proposal, then please feel free to submit a patch. Or would: Enable conditional-move operations unconditionally. be preferable? Last but not least, did my explanation help with the translation?
[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 --- Comment #4 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:80d126ba99f4b9bc64d4861b3c4bae666497f2d4 commit r14-9160-g80d126ba99f4b9bc64d4861b3c4bae666497f2d4 Author: Steve Kargl Date: Fri Feb 23 22:05:04 2024 +0100 Fortran: ALLOCATE statement, SOURCE/MOLD expressions with subrefs [PR114024] PR fortran/114024 gcc/fortran/ChangeLog: * trans-stmt.cc (gfc_trans_allocate): When a source expression has substring references, part-refs, or %re/%im inquiries, wrap the entity in parentheses to force evaluation of the expression. gcc/testsuite/ChangeLog: * gfortran.dg/allocate_with_source_27.f90: New test. * gfortran.dg/allocate_with_source_28.f90: New test. Co-Authored-By: Harald Anlauf
[Bug target/114028] [14] RISC-V rv64gcv_zvl256b: miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114028 --- Comment #3 from GCC Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:85c12ae8b80902ed46c97f33dbb61533e07f2905 commit r14-9159-g85c12ae8b80902ed46c97f33dbb61533e07f2905 Author: Robin Dapp Date: Thu Feb 22 13:40:55 2024 +0100 RISC-V: Fix vec_init for simple sequences [PR114028]. For a vec_init (_a, _a, _a, _a) with _a of mode DImode we try to construct a "superword" of two "_a"s. This only works for modes < Pmode when we can "shift and or" both halves into one Pmode register. This patch disallows the optimization for inner_mode == Pmode and emits a simple broadcast in such a case. gcc/ChangeLog: PR target/114028 * config/riscv/riscv-v.cc (rvv_builder::can_duplicate_repeating_sequence_p): Return false if inner mode is already Pmode. (rvv_builder::is_all_same_sequence): New function. (expand_vec_init): Emit broadcast if sequence is all same. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr114028.c: New test.
[Bug target/114083] Possible word play on conditional/unconditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083 Jonathan Wakely changed: What|Removed |Added CC||macro at orcam dot me.uk --- Comment #3 from Jonathan Wakely --- CCing Maciej for clarity
[Bug fortran/77504] [11/12/13/14 Regression] "is used uninitialized" with allocatable string and array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Depends on||106089 --- Comment #32 from kargl at gcc dot gnu.org --- (In reply to Walter Spector from comment #31) > Super simple test case: > > wws@w6ws-4:~/computer/fortran/tests$ /usr/local/bin/gfortran --version > GNU Fortran (GCC) 14.0.1 20240115 (experimental) > Copyright (C) 2024 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > wws@w6ws-4:~/computer/fortran/tests$ cat a.f90 > program catenate_test > implicit none > > integer, allocatable :: a(:) > > a = (/ 1, 3, 5 /) > > print *, 'size(a) =', size (a) > print *, 'a =', a > > end program > wws@w6ws-4:~/computer/fortran/tests$ /usr/local/bin/gfortran -o a a.f90 > wws@w6ws-4:~/computer/fortran/tests$ /usr/local/bin/gfortran -Wall -o a a.f90 > a.f90:6:19: > > 6 | a = (/ 1, 3, 5 /) > | ^ > Warning: ‘a.offset’ is used uninitialized [-Wuninitialized] > a.f90:4:30: > > 4 | integer, allocatable :: a(:) > | ^ > note: ‘a’ declared here > a.f90:6:19: > > 6 | a = (/ 1, 3, 5 /) > | ^ > Warning: ‘a.dim[0].lbound’ is used uninitialized [-Wuninitialized] > a.f90:4:30: > > 4 | integer, allocatable :: a(:) > | ^ > note: ‘a’ declared here > a.f90:6:19: > > 6 | a = (/ 1, 3, 5 /) > | ^ > Warning: ‘a.dim[0].ubound’ is used uninitialized [-Wuninitialized] > a.f90:4:30: > > 4 | integer, allocatable :: a(:) > | ^ > note: ‘a’ declared here > a.f90:6:19: > > 6 | a = (/ 1, 3, 5 /) > | ^ > Warning: ‘a.dim[0].lbound’ may be used uninitialized [-Wmaybe-uninitialized] > a.f90:4:30: > > 4 | integer, allocatable :: a(:) > | ^ > note: ‘a’ declared here > a.f90:6:19: > > 6 | a = (/ 1, 3, 5 /) > | ^ > Warning: ‘a.dim[0].ubound’ may be used uninitialized [-Wmaybe-uninitialized] > a.f90:4:30: > > 4 | integer, allocatable :: a(:) > | ^ > note: ‘a’ declared here > wws@w6ws-4:~/computer/fortran/tests$ ./a > size(a) = 3 > a = 1 3 5 > wws@w6ws-4:~/computer/fortran/tests$ See ttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=106089 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106089 [Bug 106089] false positives with -Wuninitialized for allocation on assignment
[Bug target/114083] Possible word play on conditional/unconditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083 --- Comment #2 from Roland Illig --- I don't understand why the word 'unconditionally' is necessary or useful here. Isn't the option -mmovcc by itself already a condition? That would make the word 'unconditionally' wrong.
[Bug target/114083] Possible word play on conditional/unconditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083 --- Comment #1 from Andrew Pinski --- This is not a play on words though. The flag enables the use of "conditional moves" always (unconditionally).
[Bug driver/114082] Guidelines for options are empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082 --- Comment #1 from Roland Illig --- If you decide to keep the guidelines, here are a few ideas: * Use the simplest English you can, while still being precise. * Don't try to be funny. (See #114083 for a possible case)
[Bug target/114083] New: Possible word play on conditional/unconditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083 Bug ID: 114083 Summary: Possible word play on conditional/unconditional Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- Target: riscv riscv.opts says: > mmovcc > Target Var(TARGET_MOVCC) > Enable conditional moves unconditionally. Is the conditional/unconditional a play of words? As the German translator, I find it more confusing than helpful. Or is there a deeper meaning? In that case, the option description should be longer.
[Bug target/66874] RFE: x86_64_fallback_frame_state more robust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874 --- Comment #5 from Andreas Schwab --- If the unwinder crashes you have either incorrect unwind info or a corrupted stack. Neither should be papered over.
[Bug preprocessor/114082] New: Guidelines for options are empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082 Bug ID: 114082 Summary: Guidelines for options are empty Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Options.html The section is empty, and it has been so since its creation in 2018. When I saw that section, I wasn't sure whether this was a technical error on the web server (unlikely but still possible) or in the .texi processing. Since the section has been missing since 2018, it may be better to remove it completely. Or, alternatively, write down the most common consensus, to be amended later.
[Bug fortran/77504] [11/12/13/14 Regression] "is used uninitialized" with allocatable string and array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504 Walter Spector changed: What|Removed |Added CC||w6ws at earthlink dot net --- Comment #31 from Walter Spector --- Super simple test case: wws@w6ws-4:~/computer/fortran/tests$ /usr/local/bin/gfortran --version GNU Fortran (GCC) 14.0.1 20240115 (experimental) Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. wws@w6ws-4:~/computer/fortran/tests$ cat a.f90 program catenate_test implicit none integer, allocatable :: a(:) a = (/ 1, 3, 5 /) print *, 'size(a) =', size (a) print *, 'a =', a end program wws@w6ws-4:~/computer/fortran/tests$ /usr/local/bin/gfortran -o a a.f90 wws@w6ws-4:~/computer/fortran/tests$ /usr/local/bin/gfortran -Wall -o a a.f90 a.f90:6:19: 6 | a = (/ 1, 3, 5 /) | ^ Warning: ‘a.offset’ is used uninitialized [-Wuninitialized] a.f90:4:30: 4 | integer, allocatable :: a(:) | ^ note: ‘a’ declared here a.f90:6:19: 6 | a = (/ 1, 3, 5 /) | ^ Warning: ‘a.dim[0].lbound’ is used uninitialized [-Wuninitialized] a.f90:4:30: 4 | integer, allocatable :: a(:) | ^ note: ‘a’ declared here a.f90:6:19: 6 | a = (/ 1, 3, 5 /) | ^ Warning: ‘a.dim[0].ubound’ is used uninitialized [-Wuninitialized] a.f90:4:30: 4 | integer, allocatable :: a(:) | ^ note: ‘a’ declared here a.f90:6:19: 6 | a = (/ 1, 3, 5 /) | ^ Warning: ‘a.dim[0].lbound’ may be used uninitialized [-Wmaybe-uninitialized] a.f90:4:30: 4 | integer, allocatable :: a(:) | ^ note: ‘a’ declared here a.f90:6:19: 6 | a = (/ 1, 3, 5 /) | ^ Warning: ‘a.dim[0].ubound’ may be used uninitialized [-Wmaybe-uninitialized] a.f90:4:30: 4 | integer, allocatable :: a(:) | ^ note: ‘a’ declared here wws@w6ws-4:~/computer/fortran/tests$ ./a size(a) = 3 a = 1 3 5 wws@w6ws-4:~/computer/fortran/tests$
[Bug middle-end/114081] [14 regression] ICE in verify_dominators when building php-8.3.3 (error: dominator of 16 should be 111, not 3) since r14-6822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
--- Comment #6 from Tamar Christina ---
slightly cleaned up testcase
---
typedef struct filter_list_entry {
const char *name;
int id;
void (*function)();
} filter_list_entry;
static const filter_list_entry filter_list[9] = {0};
void php_zval_filter(int filter, int id1) {
filter_list_entry filter_func;
int size = 9;
for (int i = 0; i < size; ++i) {
if (filter_list[i].id == filter) {
filter_func = filter_list[i];
goto done;
}
}
#pragma GCC novector
for (int i = 0; i < size; ++i) {
if (filter_list[i].id == 0x0204) {
filter_func = filter_list[i];
goto done;
}
}
done:
if (!filter_func.id)
filter_func.function();
}
---
seems to happen because it's doing an inner loop vect with two loops that have
early exits to the same destination.
if (multiple_exits_p)
{
update_loop = new_loop;
doms = get_all_dominated_blocks (CDI_DOMINATORS, loop->header);
for (unsigned i = 0; i < doms.length (); ++i)
if (flow_bb_inside_loop_p (loop, doms[i]))
doms.unordered_remove (i);
}
was supposed to update the dominators but something goes wrong.
Mine, but for monday..
[Bug middle-end/114081] [14 regression] ICE in verify_dominators when building php-8.3.3 (error: dominator of 16 should be 111, not 3) since r14-6822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/114081] [14 regression] ICE in verify_dominators when building php-8.3.3 (error: dominator of 16 should be 111, not 3) since r14-6822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||tnfchris at gcc dot gnu.org Summary|[14 regression] ICE in |[14 regression] ICE in |verify_dominators when |verify_dominators when |building php-8.3.3 (error: |building php-8.3.3 (error: |dominator of 16 should be |dominator of 16 should be |111, not 3) |111, not 3) since r14-6822 --- Comment #5 from Jakub Jelinek --- Bisected to r14-6822-g01f4251b8775c832a92d55e2df57c9ac72eaceef
[Bug middle-end/114081] [14 regression] ICE in verify_dominators when building php-8.3.3 (error: dominator of 16 should be 111, not 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081 --- Comment #4 from Andrew Pinski --- (In reply to Sam James from comment #1) > I can reproduce with: gcc -c ./ext/filter/filter.i -march=znver2 > -fno-vect-cost-model -O3. `-O3 -fno-vect-cost-model -mavx2` is enough with my reduced testcase.
[Bug middle-end/114081] [14 regression] ICE in verify_dominators when building php-8.3.3 (error: dominator of 16 should be 111, not 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-23 --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug middle-end/114081] [14 regression] ICE in verify_dominators when building php-8.3.3 (error: dominator of 16 should be 111, not 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081 --- Comment #2 from Andrew Pinski --- Created attachment 57515 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57515&action=edit Reduced
[Bug tree-optimization/114068] [14 regression] ICE when building darktable-4.6.1 (error: PHI node with wrong VUSE on edge from BB 25) since r14-8768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068 --- Comment #14 from Tamar Christina --- patch submitted https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646415.html
[Bug c++/113083] [14 Regression][arm] ICE in fold_convert_loc, at fold-const.cc:2602 since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug c++/113083] [14 Regression][arm] ICE in fold_convert_loc, at fold-const.cc:2602 since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083 --- Comment #8 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fdf9df9d55802e1d8ff0bd14585ea61b2bb9d798 commit r14-9158-gfdf9df9d55802e1d8ff0bd14585ea61b2bb9d798 Author: Jakub Jelinek Date: Fri Feb 23 18:55:12 2024 +0100 c++: Fix ICE due to folding a call to constructor on cdtor_returns_this arches (aka arm32) [PR113083] When targetm.cxx.cdtor_returns_this () (aka on arm32 TARGET_AAPCS_BASED) constructor is supposed to return this pointer, but when we cp_fold such a call, we don't take that into account and just INIT_EXPR the object, so we can later ICE during gimplification, because the expression doesn't have the right type. 2024-02-23 Jakub Jelinek PR c++/113083 * cp-gimplify.cc (cp_fold): For targetm.cxx.cdtor_returns_this () wrap r into a COMPOUND_EXPR and return folded CALL_EXPR_ARG (x, 0). * g++.dg/cpp0x/constexpr-113083.C: New test.
[Bug middle-end/114081] [14 regression] ICE in verify_dominators when building php-8.3.3 (error: dominator of 16 should be 111, not 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||ice-on-valid-code CC||pinskia at gcc dot gnu.org
[Bug c++/114078] operator new and operator delete are incorrectly acceptable as explicit object member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114078 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-23 --- Comment #1 from Andrew Pinski --- Confirmed, I thought I had saw one that was exactly the same as this but it seems maybe I was wrong.
[Bug middle-end/114073] during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114073 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2024-02-23 --- Comment #1 from Jakub Jelinek --- Created attachment 57514 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57514&action=edit gcc14-pr114073.patch Untested fix.
[Bug target/66874] RFE: x86_64_fallback_frame_state more robust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874 --- Comment #4 from Sam James --- I was just going off "incorrect debug info" in comment 0 given it's the only thing I changed recently. If not, then I've got no idea. If I were sure it were dwz, I'd file a bug there ;)
[Bug target/66874] RFE: x86_64_fallback_frame_state more robust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- (In reply to Sam James from comment #2) > I've been going crazy hitting this recently (see e.g. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068#c2). > > pinskia pointed me here and I fear I might be hitting this as a result of > dwz optimised debug info on gcc (as it's the only recent change I can think > of). How could dwz have anything to do with this? The libgcc unwinder works on .eh_frame sections. dwz only ever modifies .debug_* sections (and .gnu_debugaltlink and perhaps throws away .gdb_index), all non-allocatable sections which the libgcc unwinder never touches.
[Bug target/114077] ICE in do_SUBST at combine.cc with aarch64 crosscompiler with -fharden-control-flow-redundancy and -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #5 from Andrew Pinski ---
This fixes patch causes the code to be rejected:
```
diff --git a/gcc/function.cc b/gcc/function.cc
index 5ffd438475e..7a0f7faa2d7 100644
--- a/gcc/function.cc
+++ b/gcc/function.cc
@@ -242,7 +242,7 @@ frame_offset_overflow (poly_int64 offset, tree func)
{
poly_uint64 size = FRAME_GROWS_DOWNWARD ? -offset : offset;
unsigned HOST_WIDE_INT limit
-= ((HOST_WIDE_INT_1U << (GET_MODE_BITSIZE (Pmode) - 1))
+= ((HOST_WIDE_INT_1U << (GET_MODE_BITSIZE (ptr_mode) - 1))
/* Leave room for the fixed part of the frame. */
- 64 * UNITS_PER_WORD);
```
Though I am not 100% sure if it is correct.
[Bug target/66874] RFE: x86_64_fallback_frame_state more robust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874
Sam James changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment #2 from Sam James ---
I've been going crazy hitting this recently (see e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068#c2).
pinskia pointed me here and I fear I might be hitting this as a result of dwz
optimised debug info on gcc (as it's the only recent change I can think of).
Anyway, this seems to help indeed:
--- a/libgcc/config/i386/linux-unwind.h
+++ b/libgcc/config/i386/linux-unwind.h
@@ -60,6 +60,11 @@ x86_64_fallback_frame_state (struct _Unwind_Context
*context,
#else
#define RT_SIGRETURN_SYSCALL 0x050f4201c0c7ULL
#endif
+
+ /* Defend against corrupted PC, PR66874 */
+ if ((unsigned long)pc < 4096)
+return _URC_END_OF_STACK;
+
if (*(unsigned char *)(pc+0) == 0x48
&& *(unsigned long long *)(pc+1) == RT_SIGRETURN_SYSCALL)
{
I've only shoved it in quickly to be able to debug something else so it's not
really ready to submit.
[Bug target/114077] ICE in do_SUBST at combine.cc with aarch64 crosscompiler with -fharden-control-flow-redundancy and -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077 Andrew Pinski changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=81874 | --- Comment #4 from Andrew Pinski --- It has nothing to do with PR 81874 . The issue happens much earlier. During expand, should have rejected this as the arrays being too large.
[Bug c/114080] Inconsistent handling of unaligned 128bit ints between GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080 --- Comment #9 from Jakub Jelinek --- Note, most not too old compilers handle small constant size memcpy as an efficient way to load/store unaligned values and it is also portable. So, instead of *dstp = *srcp ^ *bufp; if all those can be unaligned use __uint128_t t1, t2; memcpy (&t1, srcp, sizeof (t1)); memcpy (&t2, bufp, sizeof (t2)); t1 = t1 ^ t2; memcpy (dstp, &t1, sizeof (t1)); should result in decent code (unless -O0 of course).
[Bug target/114077] ICE in do_SUBST at combine.cc with aarch64 crosscompiler with -fharden-control-flow-redundancy and -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077 --- Comment #2 from Andrew Pinski --- Oh yes because I am building without `--enable-checking=release` .
[Bug target/114077] ICE in do_SUBST at combine.cc with aarch64 crosscompiler with -fharden-control-flow-redundancy and -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #3 from Andrew Pinski ---
#5 0x0110cb3f in simplify_const_unary_operation (code=ZERO_EXTEND,
mode=E_DImode, op=0x776e0440, op_mode=E_SImode) at
../../gcc/simplify-rtx.cc:2131
2131 result = wide_int::from (op0, width, UNSIGNED);
(gdb) p op0
$1 = {> = {}, first =
0x776e0440, second = E_SImode}
(gdb) p width
|
$2 = 64
(gdb) p op0.first
|
$3 = (rtx_def *) 0x776e0440
(gdb) p debug_rtx(op0.first)
(const_int -240008 [0x70f2e7f8])
$4 = void
[Bug target/114077] ICE in do_SUBST at combine.cc with aarch64 crosscompiler with -fharden-control-flow-redundancy and -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #1 from Andrew Pinski ---
I get a different ICE:
t5.c: In function ‘foo’:
|
t5.c:9:1: internal compiler error: in decompose, at rtl.h:2298
|
9 | foo (void) /* { dg-error "exceeds maximum" } */
|
| ^~~
|
0x4e82fc wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
../../gcc/rtl.h:2298
0x4e82fc wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
../../gcc/wide-int.h:1089
0x4e82fc generic_wide_int
>::generic_wide_int >(std::pair const&)
../../gcc/wide-int.h:847
0x4e82fc simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc/simplify-rtx.cc:1991
0xd46d92 simplify_context::simplify_unary_operation(rtx_code, machine_mode,
rtx_def*, machine_mode)
../../gcc/simplify-rtx.cc:889
0x90aea8 simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc/rtl.h:3486
0x90aea8 convert_memory_address_addr_space_1(scalar_int_mode, rtx_def*,
unsigned char, bool, bool)
../../gcc/explow.cc:330
0x90b0c9 convert_memory_address_addr_space_1(scalar_int_mode, rtx_def*,
unsigned char, bool, bool)
../../gcc/explow.cc:375
0x90b1b9 convert_memory_address_addr_space(scalar_int_mode, rtx_def*, unsigned
char)
../../gcc/explow.cc:429
0x90b1b9 memory_address_addr_space(machine_mode, rtx_def*, unsigned char)
../../gcc/explow.cc:443
0x930da4 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.cc:11720
0x94148a expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../gcc/expr.h:316
0x94148a expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.cc:6397
0x7fab67 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3992
0x7fab67 expand_gimple_stmt
../../gcc/cfgexpand.cc:4071
0x7ffc40 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6127
0x801d06 execute
../../gcc/cfgexpand.cc:6866
[Bug target/113986] [14 regression] Build failure on aarch64-linux-musl or if ifunc support is disabled (error: 'export_load_16' aliased to undefined symbol 'libat_load_16')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113986 --- Comment #4 from Wilco --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646408.html
[Bug c/114080] Inconsistent handling of unaligned 128bit ints between GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080 --- Comment #8 from Chris Rapier --- My apologies for misunderstanding and for coming across as aggressive in my last response. This section of the code is about 15 years old so it hasn't, obviously, been subject to a close enough review until now. We'll be working on fixing that. I really do want to thank you all for the insight. This has been very helpful and, hopefully, we'll have a performative fix soon. Thanks again for this. Chris
[Bug middle-end/114081] [14 regression] ICE in verify_dominators when building php-8.3.3 (error: dominator of 16 should be 111, not 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081 --- Comment #1 from Sam James --- I can reproduce with: gcc -c ./ext/filter/filter.i -march=znver2 -fno-vect-cost-model -O3.
[Bug middle-end/114081] New: [14 regression] ICE in verify_dominators when building php-8.3.3 (error: dominator of 16 should be 111, not 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Bug ID: 114081
Summary: [14 regression] ICE in verify_dominators when building
php-8.3.3 (error: dominator of 16 should be 111, not
3)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Created attachment 57513
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57513&action=edit
filter.i.xz
(I need to work around another problem with broken unwinding, so someone else
will need to post a proper bt here.)
```
$ x86_64-pc-linux-gnu-cc -Iext/filter/
-I/var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli/ext/filter/
-I/var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli/include
-I/var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli/main
-I/var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli
-I/usr/include/valgrind
-I/var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli/ext/date/lib
-I/usr/include/libxml2
-I/var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli/ext/mbstring/libmbfl
-I/var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli/ext/mbstring/libmbfl/mbfl
-I/usr/include/pspell
-I/var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli/TSRM
-I/var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli/Zend -D_GNU_SOURCE
-fno-common -Wstrict-prototypes -Wformat-truncation -Wlogical-op
-Wduplicated-cond -Wno-clobbered -Wall -Wextra -Wno-unused-parameter
-Wno-sign-compare -O3 -march=native -mtls-dialect=gnu2
-fno-semantic-interposition -pipe -fno-vect-cost-model -Wa,-O2
-Wa,-mtune=znver2 -fdiagnostics-color=always -fdiagnostics-urls=never
-frecord-gcc-switches -Wreturn-type -Walloc-size -Wfree-nonheap-object
-Wstrict-aliasing=2 -Wbuiltin-declaration-mismatch -Wformat -Wformat-security
-Waddress -Warray-bounds -Wfree-nonheap-object -Wint-to-pointer-cast -Wmain
-Wnonnull -Wodr -Wreturn-type -Wsizeof-pointer-memaccess -Wstrict-aliasing
-Wstring-compare -Wuninitialized -Wvarargs -fvisibility=hidden
-Wimplicit-fallthrough=1 -DZEND_SIGNALS -DZEND_ENABLE_STATIC_TSRMLS_CACHE=1
-c /var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli/ext/filter/filter.c
-o ext/filter/filter.lo -MMD -MF ext/filter/filter.dep -MT
ext/filter/filter.lo -save-temps
x86_64-pc-linux-gnu-cc: warning: ‘-pipe’ ignored because ‘-save-temps’
specified
/var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli/ext/filter/filter.c:
In function ‘php_zval_filter.constprop’:
/var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli/ext/filter/filter.c:247:13:
error: dominator of 16 should be 111, not 3
247 | static void php_zval_filter(zval *value, zend_long filter, zend_long
flags, zval *options, char* charset, bool copy) /* {{{ */
| ^~~
during GIMPLE pass: vect
/var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli/ext/filter/filter.c:247:13:
internal compiler error: in verify_dominators, at dominance.cc:1194
0x563590c8a390 verify_dominators(cdi_direction) [clone .constprop.0]
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/dominance.cc:1194
/var/tmp/portage/dev-lang/php-8.3.3/work/sapis-build/cli/ext/filter/filter.c:247:13:
internal compiler error: Segmentation fault
```
[Bug c/114080] Inconsistent handling of unaligned 128bit ints between GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080 --- Comment #7 from Andrew Pinski --- (In reply to Chris Rapier from comment #5) > So what you are saying is that behaviour *has* changed and what was a valid > operation for 15 years is now invalid. I'm not mad about that. I just needed > to know. behavior didn't change, it was always undefined. -fsanitize=undefined has been catching it almost for the last 10 years (since r5-2363-g944fa280bc92d1).
[Bug c/114080] Inconsistent handling of unaligned 128bit ints between GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- (In reply to Chris Rapier from comment #5) > So what you are saying is that behaviour *has* changed and what was a valid > operation for 15 years is now invalid. I'm not mad about that. I just needed > to know. No. Please read the above comments again. The testcase has been always invalid, but invoking undefined behavior doesn't mean you always get a segfault, that would then be defined behavior. It can as well seem to do what the programmer expected it to do, or do something completely different. See e.g. https://blog.regehr.org/archives/213 for more details.
[Bug c/114080] Inconsistent handling of unaligned 128bit ints between GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080 --- Comment #5 from Chris Rapier --- So what you are saying is that behaviour *has* changed and what was a valid operation for 15 years is now invalid. I'm not mad about that. I just needed to know.
[Bug target/113059] [15 regression] fftw fails tests for -O3 -m32 -march=znver2 since r14-6210-ge44ed92dbbe9d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059 --- Comment #27 from Sam James --- Can someone sanity-check me on this by trying the instructions at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114079#c0? I think I can still hit the original crash, it's just flaky (it might pass sometimes).
[Bug target/113059] [15 regression] fftw fails tests for -O3 -m32 -march=znver2 since r14-6210-ge44ed92dbbe9d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059 --- Comment #26 from Sam James --- *** Bug 114079 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/114079] [14 regression] fftw fails tests again with -O3 -march=znver2 -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114079 Sam James changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Sam James --- Actually, I think the test is really flaky (sometimes it pases, but it'll fail if you try it a few times). If I checkout Jakub's fix from PR113059 in a loop, it still fails. It's surely the same thing then? *** This bug has been marked as a duplicate of bug 113059 ***
[Bug c/114080] Inconsistent handling of unaligned 128bit ints between GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080 --- Comment #4 from Jonathan Wakely --- You could have checked this very easily using -fsanitize=undefined just like it asks you to at https://gcc.gnu.org/bugs/ and at the top of the page when you created this bug. dst is 512-bit aligned (0x10112c0) src is 32-bit aligned (0x10112e4) buf is 64-bit aligned (0x1011308) al.c:41:72: runtime error: load of misaligned address 0x010112e4 for type '__int128 unsigned', which requires 16 byte alignment 0x010112e4: note: pointer points here 00 00 00 00 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 00 00 00 21 00 00 00 00 00 00 00 ^ al.c:41:46: runtime error: load of misaligned address 0x010112e4 for type '__int128 unsigned', which requires 16 byte alignment 0x010112e4: note: pointer points here 00 00 00 00 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 00 00 00 21 00 00 00 00 00 00 00 ^ src: 0x10101010101010101010101010101010 al.c:42:72: runtime error: load of misaligned address 0x01011308 for type '__int128 unsigned', which requires 16 byte alignment 0x01011308: note: pointer points here 00 00 00 00 00 08 10 18 20 28 30 38 40 48 50 58 60 68 70 78 11 04 00 00 00 00 00 00 73 72 63 3a ^ al.c:42:46: runtime error: load of misaligned address 0x01011308 for type '__int128 unsigned', which requires 16 byte alignment 0x01011308: note: pointer points here 00 00 00 00 00 08 10 18 20 28 30 38 40 48 50 58 60 68 70 78 11 04 00 00 00 00 00 00 73 72 63 3a ^ buf: 0x78706860585048403830282018100800 dst: 0x xoring... al.c:47:10: runtime error: load of misaligned address 0x010112e4 for type '__int128 unsigned', which requires 16 byte alignment 0x010112e4: note: pointer points here 00 00 00 00 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 00 00 00 21 00 00 00 00 00 00 00 ^ al.c:47:18: runtime error: load of misaligned address 0x01011308 for type '__int128 unsigned', which requires 16 byte alignment 0x01011308: note: pointer points here 00 00 00 00 00 08 10 18 20 28 30 38 40 48 50 58 60 68 70 78 11 04 00 00 00 00 00 00 78 6f 72 69 ^ success! dst: 0x68607870484058502820383008001810
[Bug c/114080] Inconsistent handling of unaligned 128bit ints between GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080 --- Comment #3 from Jakub Jelinek --- The testcase segfaults since r13-1607-gc3ed9e0d6e96d8697e4bab994f8acbc5506240ee when the backend started using more aggressively vector instructions for operations like the 128-bit logical ops, but that doesn't change anything on the testcase being invalid. Don't do that.
[Bug c/114080] Inconsistent handling of unaligned 128bit ints between GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- The alignment requirement for int128_t has always been 16byte aligned. So if you cast an unaligned pointer to int128_t pointer you run into c undefined behavior. Just happens now gcc will use the sse registers to do things like xor and such and the sse loads trap on unaligned.
[Bug c/114080] Inconsistent handling of unaligned 128bit ints between GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080 --- Comment #1 from Jakub Jelinek --- That is undefined behavior, __int128/__int128_t/__uint128_t needs 16-byte alignment.
[Bug c/114080] New: Inconsistent handling of 128bit ints between GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
Bug ID: 114080
Summary: Inconsistent handling of 128bit ints between GCC
versions
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rapier at psc dot edu
Target Milestone: ---
I'm attempting to XOR 2 128bit ints in 13.2.1 and am consistently getting a
segfault when optimization is set at -O2. The problem is that this behaviour
doesn't happen when using older versions of GCC. As an aside, what we are
trying to do is XOR a stream of data as quickly as possible so using 128bit
ints reduced the number of XORs we need to perform.
I've been using the following MWE to test this:
#include
#include
#include
/* just informative */
void printAlignment(void *ptr, char *label) {
for (int ta = 64; ta > 0; ta /= 2)
if ((uint64_t) ptr % ta == 0) {
printf("%s is %3u-bit aligned (%p)\n", label, ta * 8,
ptr);
return;
}
}
/* offset is the desired alignment in BYTES */
/* startptr exists to free it later */
void * misaligned_128bit_malloc(size_t offset, void **startptr) {
*startptr = malloc(16 + offset); /* 16 bytes = 128 bits */
void * ret = *startptr + 1; /* force minimal misalignment */
while ((uint64_t) ret % offset != 0) /* iterate until aligned */
ret = ret + 1;
return ret;
}
int main() {
__uint128_t *dstp, *srcp, *bufp;
void *dst, *src, *buf;
dstp = misaligned_128bit_malloc(16, &dst);
srcp = misaligned_128bit_malloc(4, &src);
bufp = misaligned_128bit_malloc(8, &buf);
printAlignment(dstp, "dst");
printAlignment(srcp, "src");
printAlignment(bufp, "buf");
*dstp = 0;
/* fill in some dummy data */
for(int i=0; i<16; i++) ((uint8_t *) srcp)[i] = 0x10;
for(int i=0; i<16; i++) ((uint8_t *) bufp)[i] = i << 3;
printf("src: 0x%016lx%016lx\n", (uint64_t) (*srcp >> 64), (uint64_t)
(*srcp));
printf("buf: 0x%016lx%016lx\n", (uint64_t) (*bufp >> 64), (uint64_t)
(*bufp));
printf("dst: 0x%016lx%016lx\n", (uint64_t) (*dstp >> 64), (uint64_t)
(*dstp));
printf("xoring...\n");
fflush(stdout);
*dstp = *srcp ^ *bufp;
printf("success!\n");
printf("dst: 0x%016lx%016lx\n", (uint64_t) (*dstp >> 64), (uint64_t)
(*dstp));
free(dst);
free(src);
free(buf);
return 0;
}
Results:
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
~/test$ gcc -O2 mwe.c -o mwe
$ ./mwe
dst is 128-bit aligned (0x5637185eb2b0)
src is 32-bit aligned (0x5637185eb2d4)
buf is 64-bit aligned (0x5637185eb2f8)
src: 0x10101010101010101010101010101010
buf: 0x78706860585048403830282018100800
dst: 0x
xoring...
success!
dst: 0x68607870484058502820383008001810
gcc version 13.2.1 20231011 (Red Hat 13.2.1-4) (GCC)
$ gcc -O2 mwe.c -o mwe
$ ./mwe
dst is 128-bit aligned (0x1cbc2b0)
src is 32-bit aligned (0x1cbc2d4)
buf is 64-bit aligned (0x1cbc2f8)
src: 0x10101010101010101010101010101010
buf: 0x78706860585048403830282018100800
dst: 0x
xoring...
Segmentation fault (core dumped)
gcc version 13.2.1 20231011 (Red Hat 13.2.1-4) (GCC)
$ gcc -O0 mwe.c -o mwe
$ ./mwe
dst is 128-bit aligned (0xb022b0)
src is 32-bit aligned (0xb022d4)
buf is 64-bit aligned (0xb022f8)
src: 0x10101010101010101010101010101010
buf: 0x78706860585048403830282018100800
dst: 0x
xoring...
success!
dst: 0x68607870484058502820383008001810
I don't know if this is a bug in 13.2.1 or if the might be undefined behaviour
that is now being enforced with a segfault. I've looked through the release
documents for 13.2.1 and didn't see anything that seems to indicate the latter
but I might have missed it.
Any help or insight you could provide would be appreciated.
Thanks for your time,
Chris
DeepLearn 2024: early registration March 3
*To be removed from our mailing list, please respond to this message with UNSUBSCRIBE in the subject line* -- ** 11th INTERNATIONAL SCHOOL ON DEEP LEARNING (and the Future of Artificial Intelligence) DeepLearn 2024 Porto – Maia, Portugal July 15-19, 2024 https://deeplearn.irdta.eu/2024/ ** Co-organized by: University of Maia Institute for Research Development, Training and Advice – IRDTA Brussels/London ** Early registration: March 3, 2024 ** SCOPE: DeepLearn 2024 will be a research training event with a global scope aiming at updating participants on the most recent advances in the critical and fast developing area of deep learning. Previous events were held in Bilbao, Genova, Warsaw, Las Palmas de Gran Canaria, Guimarães, Las Palmas de Gran Canaria, Luleå, Bournemouth, Bari and Las Palmas de Gran Canaria. Deep learning is a branch of artificial intelligence covering a spectrum of current frontier research and industrial innovation that provides more efficient algorithms to deal with large-scale data in a huge variety of environments: computer vision, neurosciences, speech recognition, language processing, human-computer interaction, drug discovery, health informatics, medical image analysis, recommender systems, advertising, fraud detection, robotics, games, finance, biotechnology, physics experiments, biometrics, communications, climate sciences, geographic information systems, signal processing, genomics, materials design, video technology, social systems, etc. etc. The field is also raising a number of relevant questions about robustness of the algorithms, explainability, transparency, and important ethical concerns at the frontier of current knowledge that deserve careful multidisciplinary discussion. Most deep learning subareas will be displayed, and main challenges identified through 16 four-hour and a half courses, 2 keynote lectures, 1 round table and a few hackathon-type competitions among students, which will tackle the most active and promising topics. Renowned academics and industry pioneers will lecture and share their views with the audience. The organizers are convinced that outstanding speakers will attract the brightest and most motivated students. Face to face interaction and networking will be main ingredients of the event. It will be also possible to fully participate in vivo remotely. ADDRESSED TO: Graduate students, postgraduate students and industry practitioners will be typical profiles of participants. However, there are no formal pre-requisites for attendance in terms of academic degrees, so people less or more advanced in their career will be welcome as well. Since there will be a variety of levels, specific knowledge background may be assumed for some of the courses. Overall, DeepLearn 2024 is addressed to students, researchers and practitioners who want to keep themselves updated about recent developments and future trends. All will surely find it fruitful to listen to and discuss with major researchers, industry leaders and innovators. VENUE: DeepLearn 2024 will take place in Porto, the second largest city in Portugal, recognized by UNESCO in 1996 as a World Heritage Site. The venue will be: University of Maia Avenida Carlos de Oliveira Campos - Castlo da Maia 4475-690 Maia Porto, Portugal https://www.umaia.pt/en STRUCTURE: 3 courses will run in parallel during the whole event. Participants will be able to freely choose the courses they wish to attend as well as to move from one to another. All lectures will be videorecorded. Participants will be able to watch them again for 45 days after the event. An open session will give participants the opportunity to present their own work in progress in 5 minutes. Also companies will be able to present their technical developments for 10 minutes. This year’s edition of the school will schedule hands-on activities including mini-hackathons, where participants will work in teams to tackle several machine learning challenges. Full live online participation will be possible. The organizers highlight, however, the importance of face to face interaction and networking in this kind of research training event. KEYNOTE SPEAKERS: Jiawei Han (University of Illinois Urbana-Champaign), How Can Large Language Models Contribute to Effective Text Mining? Katia Sycara (Carnegie Mellon University), Effective Multi Agent Teaming PROFESSORS AND COURSES: Luca Benini (Swiss Federal Institute of Technology Zurich), [intermediate/advanced] Open Hardware Platforms for Edge Machine Learning Gustau Camps-Valls (University of València), [intermediate] AI for Earth, Climate, and Sustainability Nitesh Chawla (University of Notre Dame), [introductory/intermediate] Intr
[Bug middle-end/114070] [12/13/14 regression] ICE when building git-2.43.2 with -mcpu=niagara4 -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114070 --- Comment #7 from Richard Biener --- Created attachment 57512 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57512&action=edit patch I am testing
[Bug tree-optimization/114010] Unwanted effects of using SSA free lists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #10 from Manolis Tsamis ---
(In reply to ptomsich from comment #9)
> (In reply to Manolis Tsamis from comment #0)
> > E.g. another loop, non canonicalized names:
> >
> > .L120:
> > ldr q30, [x0], 16
> > moviv29.2s, 0
> > ld2 {v26.16b - v27.16b}, [x4], 32
> > moviv25.4s, 0
> > zip1v29.16b, v30.16b, v29.16b
> > zip2v30.16b, v30.16b, v25.16b
> > umlal v29.8h, v26.8b, v28.8b
> > umlal2 v30.8h, v26.16b, v28.16b
> > uaddw v31.4s, v31.4s, v29.4h
> > uaddw2 v31.4s, v31.4s, v29.8h
> > uaddw v31.4s, v31.4s, v30.4h
> > uaddw2 v31.4s, v31.4s, v30.8h
> > cmp x5, x0
> > bne .L120
>
> Is it just me, or are the zip1 and zip2 instructions dead?
>
> Philipp.
They certainly look dead, but they're not because the umlal/umlal2 (and other
accumulate instructions) also read from the destination register.
There looks to be a missed optimization opportunity to use just a single `movi
v25.4s, 0` here though.
Also, looking again at the generated code in the first example:
mov v23.16b, v18.16b
mla v23.16b, v17.16b, v25.16b
If I'm correct this could be folded into just
mla v18.16b, v17.16b, v25.16b
In which case most of the movs in the first and second example could be
eliminated. To me it looks like the accumulate instructions are missing some
optimizations.
[Bug middle-end/113205] [14 Regression] internal compiler error: in backward_pass, at tree-vect-slp.cc:5346 since r14-3220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205 --- Comment #12 from Richard Sandiford --- Created attachment 57511 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57511&action=edit Candidate patch Sorry for the very slow response on this. I'm testing the attached.
[Bug c++/114076] list-initialization with assignment expression triggers wrong template instanciation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114076
--- Comment #2 from Jiang An ---
The "templatization" trick also works for GCC.
https://godbolt.org/z/8PeMMzsbb
```
template
struct holder {
holder() = default;
constexpr ~holder() {
static_assert(sizeof(T) || true);
}
};
struct Incomplete;
template // templated
struct Class {
Class();
~Class();
holder a{}; // all accept
holder b = {}; // all accept
holder c = holder{}; // only Clang rejects
};
int main() {
[[maybe_unused]] Class v; // CTAD
}
```
It's unclear to me what is not yet instantiated after the object definition.
[Bug middle-end/113205] [14 Regression] internal compiler error: in backward_pass, at tree-vect-slp.cc:5346 since r14-3220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205 Richard Sandiford changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/114076] list-initialization with assignment expression triggers wrong template instanciation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114076 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #1 from Jiang An --- Looks like a duplicate of Bug 104850 to me. GCC cares about the difference between direct/copy of initialization, not whether list-initialization or not (however, it's unfortunately that direct-non-list-initialization can't be used). > In case c, the rejection seems to me to be correct, since here the temporary > value must be destroyed by a destructor call. I don't see why there's even a temporary value since C++17. The prvalue is used to initialize the data member (via temporary materialization). The potential invocation of destructor should be in the body of constructors.
[Bug tree-optimization/114079] [14 regression] fftw fails tests again with -O3 -march=znver2 -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114079 --- Comment #1 from Sam James --- I'll bisect it now.
[Bug tree-optimization/114010] Unwanted effects of using SSA free lists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #9 from ptomsich at gcc dot gnu.org ---
(In reply to Manolis Tsamis from comment #0)
> E.g. another loop, non canonicalized names:
>
> .L120:
> ldr q30, [x0], 16
> moviv29.2s, 0
> ld2 {v26.16b - v27.16b}, [x4], 32
> moviv25.4s, 0
> zip1v29.16b, v30.16b, v29.16b
> zip2v30.16b, v30.16b, v25.16b
> umlal v29.8h, v26.8b, v28.8b
> umlal2 v30.8h, v26.16b, v28.16b
> uaddw v31.4s, v31.4s, v29.4h
> uaddw2 v31.4s, v31.4s, v29.8h
> uaddw v31.4s, v31.4s, v30.4h
> uaddw2 v31.4s, v31.4s, v30.8h
> cmp x5, x0
> bne .L120
Is it just me, or are the zip1 and zip2 instructions dead?
Philipp.
[Bug c++/104850] Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104850 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #5 from Jiang An --- Clang started to accept this since Clang 16. https://godbolt.org/z/c6vGzTP48
[Bug tree-optimization/114079] New: [14 regression] fftw fails tests again with -O3 -march=znver2 -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114079 Bug ID: 114079 Summary: [14 regression] fftw fails tests again with -O3 -march=znver2 -m32 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- It's not the same as PR113059, although it's the same initial symptoms :( ``` wget https://www.fftw.org/fftw-3.3.10.tar.gz && tar xvf fftw-3.3.10.tar.xz ./configure CFLAGS="-O3 -march=znver2 -m32 -ggdb3" make -j$(nproc) make check -j$(nproc) # should fail, probably on tests/bench --verify okd6912o01 (you can extract the verify param from gdb) ``` ``` $ libtool --mode=execute gdb --args /home/sam/data/fftw/fftw-3.3.10/tests/bench --verify okd6912o01 Reading symbols from /home/sam/data/fftw/fftw-3.3.10/tests/bench... (gdb) r Starting program: /home/sam/data/fftw/fftw-3.3.10/tests/bench --verify okd6912o01 [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. r2cf_32 (R0=0x9ee0, R1=0x9ff0, Cr=0x9ee0, Ci=, rs=, csr=0x566c2080, csi=0x0, v=, ivs=1, ovs=1) at r2cf_32.c:490 490 Ci[WS(csi, 8)] = T29 - T28; (gdb) bt #0 r2cf_32 (R0=0x9ee0, R1=0x9ff0, Cr=0x9ee0, Ci=, rs=, csr=0x566c2080, csi=0x0, v=, ivs=1, ovs=1) at r2cf_32.c:490 #1 0x5663e323 in dobatch_r2hc (ego=0x566c1780, I=0x566b30b0, O=0x566b30b0, buf=0x9ee0, batchsz=1) at direct-r2c.c:91 #2 0x5663e44d in iterate (ego=0x566c1780, I=, O=, dobatch=) at direct-r2c.c:142 #3 0x565a86e5 in fftw_rdft_solve (ego_=0x566c1780, p_=0x566c1c50) at solve.c:29 #4 0x56563d8b in measure (pln=, p=, iter=1) at timer.c:136 #5 fftw_measure_execution_time (plnr=0x566a9710, pln=0x566c1780, p=0x566c1c50) at timer.c:159 #6 0x56561053 in evaluate_plan (ego=ego@entry=0x566a9710, pln=pln@entry=0x566c1780, p=p@entry=0x566c1c50) at planner.c:460 #7 0x565620a3 in search0 (ego=ego@entry=0x566a9710, p=p@entry=0x566c1c50, slvndx=slvndx@entry=0xc2bc, flagsp=) at planner.c:529 #8 0x56562467 in search (ego=0x566a9710, p=0x566c1c50, slvndx=0xc2bc, flagsp=0xc2c0) at planner.c:600 #9 mkplan (ego=, p=) at planner.c:711 #10 0x56562f00 in fftw_mkplan_d (ego=0x566a9710, p=0x566c1c50) at planner.c:970 #11 0x5663f3eb in mkcldw (ego_=0x566ac3a0, kind=R2HC00, r=32, m=216, ms=1, v=1, vs=0, mstart=0, mcount=109, IO=0x566b30b0, plnr=0x566a9710) at hc2hc-direct.c:205 #12 0x565a26d0 in mkplan (ego_=0x566ac3a0, p_=0x566c1830, plnr=0x566a9710) at hc2hc.c:142 #13 0x56562151 in invoke_solver (ego=0x566a9710, p=, s=, nflags=) at planner.c:486 #14 search0 (ego=ego@entry=0x566a9710, p=p@entry=0x566c1830, slvndx=slvndx@entry=0xc4ec, flagsp=) at planner.c:529 #15 0x56562467 in search (ego=0x566a9710, p=0x566c1830, slvndx=0xc4ec, flagsp=0xc4f0) at planner.c:600 #16 mkplan (ego=, p=) at planner.c:711 #17 0x56562f00 in fftw_mkplan_d (ego=0x566a9710, p=0x566c1830) at planner.c:970 #18 0x5662af0f in mkplan (ego_=0x566b3080, p_=0x566c0da0, plnr=0x566a9710) at reodft010e-r2hc.c:357 #19 0x56562151 in invoke_solver (ego=0x566a9710, p=, s=, nflags=) at planner.c:486 #20 search0 (ego=ego@entry=0x566a9710, p=p@entry=0x566c0da0, slvndx=slvndx@entry=0xc6cc, flagsp=) at planner.c:529 #21 0x565628a8 in search (ego=0x566a9710, p=0x566c0da0, slvndx=0xc6cc, flagsp=0xc6d0) at planner.c:600 #22 mkplan (ego=, p=) at planner.c:711 #23 0x5655ea4a in mkplan0 (plnr=0x566a9710, flags=1, prb=, hash_info=0, wisdom_state=WISDOM_NORMAL) at apiplan.c:42 #24 mkplan (plnr=0x566a9710, flags=1, prb=, hash_info=0) at apiplan.c:56 #25 fftw_mkapiplan (sign=, flags=, prb=) at apiplan.c:124 #26 0x56560464 in fftw_plan_many_r2r (rank=1, n=0xc860, howmany=1, in=0x5668e680, inembed=, istride=1, idist=1, out=0x5669bf00, onembed=0x0, ostride=1, odist=1, kind=0xc86c, flags=1) at plan-many-r2r.c:40 #27 0x5656060a in fftw_plan_r2r (rank=1, n=0xc860, in=0x5668e680, out=0x5669bf00, kind=0xc86c, flags=1) at plan-r2r.c:26 #28 0x565604ac in fftw_plan_r2r_1d (n=, in=0x5668e680, out=0x5669bf00, kind=, flags=1) at plan-r2r-1d.c:25 #29 0x5655bc19 in mkplan_r2r (p=0x5668e080, flags=1) at bench.c:451 #30 mkplan (p=0x5668e080, flags=1) at bench.c:525 #31 0x5655d980 in setup (p=0x5668e080) at fftw-bench.c:243 #32 0x56642d6b in verify (param=0xcce2 "okd6912o01", rounds=10, tol=1e-10) at verify.c:55 #33 0x5663ff99 in bench_main (argc=, argv=) at bench-main.c:107 #34 0x56559337 in main (argc=3, argv=0xca94) at main.c:38 ```
[Bug target/112922] [14 Regression] 465.tonto from SPECFP 2006 fails train run on Aarch64-linux with -O2 and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112922 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Richard Sandiford --- Assume fixed by the patches for PR113295. Please reopen if not.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 112922, which changed state. Bug 112922 Summary: [14 Regression] 465.tonto from SPECFP 2006 fails train run on Aarch64-linux with -O2 and -flto https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112922 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/113295] [14 Regression] SPEC 2006 416.gamess miscompares on Aarch64 when built with -Ofast -mcpu=native since g:2f46e3578d45ff060a0a329cb39d4f52878f9d5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Richard Sandiford --- Fixed.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 113295, which changed state. Bug 113295 Summary: [14 Regression] SPEC 2006 416.gamess miscompares on Aarch64 when built with -Ofast -mcpu=native since g:2f46e3578d45ff060a0a329cb39d4f52878f9d5a https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/113613] [14 Regression] Missing ldp/stp optimization since r14-6290-g9f0f7d802482a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Sandiford --- Fixed.
[Bug target/113613] [14 Regression] Missing ldp/stp optimization since r14-6290-g9f0f7d802482a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613 --- Comment #8 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:ff442719cdb64c9df9d069af88e90d51bee6fb56 commit r14-9157-gff442719cdb64c9df9d069af88e90d51bee6fb56 Author: Richard Sandiford Date: Fri Feb 23 14:12:55 2024 + aarch64: Spread out FPR usage between RA regions [PR113613] early-ra already had code to do regrename-style "broadening" of the allocation, to promote scheduling freedom. However, the pass divides the function into allocation regions and this broadening only worked within a single region. This meant that if a basic block contained one subblock of FPR use, followed by a point at which no FPRs were live, followed by another subblock of FPR use, the two subblocks would tend to reuse the same registers. This in turn meant that it wasn't possible to form LDP/STP pairs between them. The failure to form LDPs and STPs in the testcase was a regression from GCC 13. The patch adds a simple heuristic to prefer less recently used registers in the event of a tie. gcc/ PR target/113613 * config/aarch64/aarch64-early-ra.cc (early_ra::m_current_region): New member variable. (early_ra::m_fpr_recency): Likewise. (early_ra::start_new_region): Bump m_current_region. (early_ra::allocate_colors): Prefer less recently used registers in the event of a tie. Add a comment to explain why we prefer(ed) higher-numbered registers. (early_ra::find_oldest_color): Prefer less recently used registers here too. (early_ra::finalize_allocation): Update recency information for allocated registers. (early_ra::process_blocks): Initialize m_current_region and m_fpr_recency. gcc/testsuite/ PR target/113613 * gcc.target/aarch64/pr113613.c: New test.
[Bug target/113295] [14 Regression] SPEC 2006 416.gamess miscompares on Aarch64 when built with -Ofast -mcpu=native since g:2f46e3578d45ff060a0a329cb39d4f52878f9d5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295 --- Comment #8 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:9f105cfdc1bca6c9224384b3044c4ca5894e1e4c commit r14-9156-g9f105cfdc1bca6c9224384b3044c4ca5894e1e4c Author: Richard Sandiford Date: Fri Feb 23 14:12:55 2024 + aarch64: Tighten early-ra chain test for wide registers [PR113295] Most code in early-ra used is_chain_candidate to check whether we should chain two allocnos. This included both tests that matter for correctness and tests for certain heuristics. Once that test passes for one pair of allocnos, we test whether it's safe to chain the containing groups (which might contain multiple allocnos for x2, x3 and x4 modes). This test used an inline test for correctness only, deliberately skipping the heuristics. However, this instance of the test was missing some handling of equivalent allocnos. This patch fixes things by making is_chain_candidate take a strictness parameter: correctness only, or correctness + heuristics. It then makes the group-chaining test use the correctness version rather than trying to replicate it inline. gcc/ PR target/113295 * config/aarch64/aarch64-early-ra.cc (early_ra::test_strictness): New enum. (early_ra::is_chain_candidate): Add a strictness parameter to control whether only correctness matters, or whether both correctness and heuristics should be used. Handle multiple levels of equivalence. (early_ra::find_related_start): Update call accordingly. (early_ra::strided_polarity_pref): Likewise. (early_ra::form_chains): Likewise. (early_ra::try_to_chain_allocnos): Use is_chain_candidate in correctness mode rather than trying to inline the test. gcc/testsuite/ PR target/113295 * gcc.target/aarch64/pr113295-2.c: New test.
[Bug target/113295] [14 Regression] SPEC 2006 416.gamess miscompares on Aarch64 when built with -Ofast -mcpu=native since g:2f46e3578d45ff060a0a329cb39d4f52878f9d5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295 --- Comment #7 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:8a16e06da97f51574cfad17e2cece2e58571305d commit r14-9155-g8a16e06da97f51574cfad17e2cece2e58571305d Author: Richard Sandiford Date: Fri Feb 23 14:12:54 2024 + aarch64: Add missing early-ra bookkeeping [PR113295] 416.gamess showed up two wrong-code bugs in early-ra. This patch fixes the first of them. It was difficult to reduce the source code to something that would meaningfully show the situation, so the testcase uses a direct RTL sequence instead. In the sequence: (a) register <2> is set more than once (b) register <2> is copied to a temporary (<4>) (c) register <2> is the destination of an FCSEL between <4> and another value (<5>) (d) <4> and <2> are equivalent for <4>'s live range (e) <5>'s and <2>'s live ranges do not intersect, and there is a pseudo-copy between <5> and <2> On its own, (d) implies that <4> can be treated as equivalent to <2>. And on its own, (e) implies that <5> can share <2>'s register. But <4>'s and <5>'s live ranges conflict, meaning that they cannot both share the register together. A bit of missing bookkeeping meant that the mechanism for detecting this didn't fire. We therefore ended up with an FCSEL in which both inputs were the same register. gcc/ PR target/113295 * config/aarch64/aarch64-early-ra.cc (early_ra::find_related_start): Account for definitions by shared registers when testing for a single register definition. (early_ra::accumulate_defs): New function. (early_ra::record_copy): If A shares B's register, fold A's definition information into B's. Fold A's use information into B's. gcc/testsuite/ PR target/113295 * gcc.dg/rtl/aarch64/pr113295-1.c: New test.
[Bug rtl-optimization/114062] "GNAT BUG DETECTED" 13.2.0 (hppa-linux-gnu) in remove, at alloc-pool.h:437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114062 --- Comment #3 from dave.anglin at bell dot net --- On 2024-02-23 4:09 a.m., doko at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114062 > > --- Comment #2 from Matthias Klose --- > this is seen when building with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 > and applying the proposed patch from PR114065. I built gcc-13 12.2.0 package successfully outside buildd on mx3210. c8000a buildd failed for the third time building gcc-14: In file included from ../../src/gcc/hash-table.h:248, from ../../src/gcc/coretypes.h:498, from ../../src/gcc/analyzer/call-details.cc:24: ../../src/gcc/vec.h:2314:51: internal compiler error: in pop, at vec.h:1056 2314 | vec::contains (const T &search) const | ^ /<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/ -B/usr/hppa-linux-gnu/bin/ -nostdinc++ -B/<>/build/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -B/<>/build/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -I/<>/build/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/<>/build/prev-hppa-linux-gnu/libstdc++-v3/include -I/<>/src/libstdc++-v3/libsupc++ -L/<>/build/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -L/<>/build/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -fno-common -DHAVE_CONFIG_H -fno-PIE -I. -Ianalyzer -I../../src/gcc -I../../src/gcc/analyzer -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libcody -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -I../../src/gcc/../libbacktrace -o analyzer/call-string.o -MT analyzer/call-string.o -MMD -MP -MF analyzer/.deps/call-string.TPo ../../src/gcc/analyzer/call-string.cc 0xd2415f cp_lexer_rollback_tokens ../../src/gcc/cp/parser.cc:1438 0xda56cf cp_parser_parse_definitely ../../src/gcc/cp/parser.cc:35798 0xd73367 cp_parser_direct_declarator ../../src/gcc/cp/parser.cc:23928 0xd72fc3 cp_parser_declarator ../../src/gcc/cp/parser.cc:23773 0xd7116f cp_parser_init_declarator ../../src/gcc/cp/parser.cc:23257 0xd9b2b7 cp_parser_single_declaration ../../src/gcc/cp/parser.cc:33240 0xd98937 cp_parser_template_declaration_after_parameters ../../src/gcc/cp/parser.cc:32793 0xd9a93f cp_parser_explicit_template_declaration ../../src/gcc/cp/parser.cc:33066 0xd9aa1f cp_parser_template_declaration_after_export ../../src/gcc/cp/parser.cc:33085 0xd5d9fb cp_parser_template_declaration ../../src/gcc/cp/parser.cc:18171 0xd546af cp_parser_declaration ../../src/gcc/cp/parser.cc:15502 0xd54cd3 cp_parser_toplevel_declaration ../../src/gcc/cp/parser.cc:15594 0xd2e99b cp_parser_translation_unit ../../src/gcc/cp/parser.cc:5279 0xe09b87 c_parse_file() ../../src/gcc/cp/parser.cc:51202 0x1200863 c_common_parse_file() ../../src/gcc/c-family/c-opts.cc:1311 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. /<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/ -B/usr/hppa-linux-gnu/bin/ -nostdinc++ -B/<>/build/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -B/<>/build/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -I/<>/build/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/<>/build/prev-hppa-linux-gnu/libstdc++-v3/include -I/<>/src/libstdc++-v3/libsupc++ -L/<>/build/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -L/<>/build/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -fno-common -DHAVE_CONFIG_H -fno-PIE -I. -Ianalyzer -I../../src/gcc -I../../src/gcc/analyzer -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libcody -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -I../../src/gcc/../libbacktrace -o analyzer/call-summary.o -MT analyzer/call-summary.o -MMD -MP -MF analyzer/.deps/call-summary.TPo ../../src/gcc/analyzer/call-summary.cc /<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/ -B/usr/hppa-linux-gnu/bin/ -nostdinc++ -B/<>/build/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -B/<>/build/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -I/<>/build/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/<>/build/prev-hppa-linux-gnu/libstdc++-v3/include -I/<>/src/libstdc++-v3/libsupc++ -L/<>/build/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -L/<>/build/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast
[Bug c++/114078] New: operator new and operator delete are incorrectly acceptable as explicit object member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114078
Bug ID: 114078
Summary: operator new and operator delete are incorrectly
acceptable as explicit object member functions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: de34 at live dot cn
Target Milestone: ---
GCC currently accepts this wrong program while it shouldn't
(https://godbolt.org/z/7jGnGqYPM), because member operator new/operator delete
are always static member functions.
#include
#include
struct S {
void* operator new(this std::size_t);
void operator delete(this S*, std::destroying_delete_t);
operator S*() const;
operator std::size_t() const;
};
int main()
{
S{}.operator new();
S{}.operator delete(std::destroying_delete);
}
Similar to https://github.com/llvm/llvm-project/issues/82249 which is fixed
recently.
[Bug target/108120] [11/12 Regression] ICE: in extract_insn, at recog.cc:2791 (on ARM with -mfpu=neon -freciprocal-math -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120 Richard Earnshaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Earnshaw --- Fixed on all active branches
[Bug target/108120] [11/12 Regression] ICE: in extract_insn, at recog.cc:2791 (on ARM with -mfpu=neon -freciprocal-math -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120 --- Comment #7 from GCC Commits --- The releases/gcc-11 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:98032b3e320a5b63309d6a843f6e97fb0506953a commit r11-11251-g98032b3e320a5b63309d6a843f6e97fb0506953a Author: Richard Earnshaw Date: Thu Feb 22 16:47:20 2024 + arm: fix ICE with vectorized reciprocal division [PR108120] The expand pattern for reciprocal division was enabled for all math optimization modes, but the patterns it was generating were not enabled unless -funsafe-math-optimizations were enabled, this leads to an ICE when the pattern we generate cannot be recognized. Fixed by only enabling vector division when doing unsafe math. gcc: PR target/108120 * config/arm/neon.md (div3): Rename from div3. Gate with ARM_HAVE_NEON__ARITH. gcc/testsuite: PR target/108120 * gcc.target/arm/neon-recip-div-1.c: New file. (cherry picked from commit 016c4eed368b80a97101f6156ed99e4c5474fbb7)
[Bug target/108120] [11/12 Regression] ICE: in extract_insn, at recog.cc:2791 (on ARM with -mfpu=neon -freciprocal-math -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:0de82d2c2ec0b7ed65a1122884feab40f90c0483 commit r12-10174-g0de82d2c2ec0b7ed65a1122884feab40f90c0483 Author: Richard Earnshaw Date: Thu Feb 22 16:47:20 2024 + arm: fix ICE with vectorized reciprocal division [PR108120] The expand pattern for reciprocal division was enabled for all math optimization modes, but the patterns it was generating were not enabled unless -funsafe-math-optimizations were enabled, this leads to an ICE when the pattern we generate cannot be recognized. Fixed by only enabling vector division when doing unsafe math. gcc: PR target/108120 * config/arm/neon.md (div3): Rename from div3. Gate with ARM_HAVE_NEON__ARITH. gcc/testsuite: PR target/108120 * gcc.target/arm/neon-recip-div-1.c: New file. (cherry picked from commit 016c4eed368b80a97101f6156ed99e4c5474fbb7)
[Bug tree-optimization/114075] [14 Regression] s390x miscompilation since r14-322
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114075 --- Comment #5 from jchrist at linux dot ibm.com --- Just sent a v2 of the patch including your suggested test and updated the commit message.
[Bug c++/105645] Template specializations are not hidden with fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105645
Julian Waters changed:
What|Removed |Added
CC||tanksherman27 at gmail dot com
--- Comment #3 from Julian Waters ---
I can confirm this on gcc 11 and higher:
#include
template
void method(T* src, T* dst, size_t length);
template<>
void method(short* src, short* dst, size_t length) {
}
template<>
void method(int* src, int* dst, size_t length) {
}
Compiled using command line:
g++ -O3 -fvisibility=hidden -std=c++14 -pedantic -Wpedantic -Wall -Werror
templates.cpp
Linked using:
g++ -shared -o libtemplates.so templates.o
When nm is run over it using nm -gDC libtemplates.so, the following symbols are
seen:
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
1110 T void method(int*, int*, unsigned long)
1100 T void method(short*, short*, unsigned long)
w __cxa_finalize
w __gmon_start__
T void method(int*, int*, unsigned long) and T void method(short*,
short*, unsigned long) should not be in the symbol table, but they are even
with -fvisibility=hidden.
Strangely, marking both methods with [[gnu::visibility("hidden")]] works and
results in both not being exported.
This was recently observed in the JDK, inside the Java HotSpot VM (see
https://github.com/openjdk/jdk/pull/17955/files#r1498933843)
Is this enough of a reproducer to get this confirmed?
[Bug tree-optimization/114075] [14 Regression] s390x miscompilation since r14-322
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114075 --- Comment #4 from jchrist at linux dot ibm.com --- (In reply to Jakub Jelinek from comment #2) > Ah, there is > https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645928.html > but that didn't come up with a testcase. > Not sure if checking FLOAT_MODE_P is the right thing, whether it wouldn't be > better to check !ANY_INTEGRAL_TYPE_P (vectype) or !INTEGRAL_TYPE_P > (TREE_TYPE (vectype)). Hi, yes, that patch was designed to fix this problem. But thinking about it, I guess your second suggestion would be better.
[Bug tree-optimization/114068] [14 regression] ICE when building darktable-4.6.1 (error: PHI node with wrong VUSE on edge from BB 25) since r14-8768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068 --- Comment #13 from Tamar Christina --- Created attachment 57510 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57510&action=edit candidate-patch1.patch candidate patch being tested. I was hoping to correct it during peeling itself when the merge block is created, but I don't have enough information there to do so.
[Bug middle-end/114070] [12/13/13 regression] ICE when building git-2.43.2 with -mcpu=niagara4 -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114070
--- Comment #6 from Richard Biener ---
So we vectorize this to
_97 = vect__4.15_91 == { 0, 0 };
vect_patt_8.17_98 = VEC_COND_EXPR <_97, { 1, 1 }, { 0, 0 }>;
_102 = vect__5.16_93 != { 0, 0 };
vect_patt_19.18_103 = VEC_COND_EXPR <_102, { 1, 1 }, { 0, 0 }>;
vect_patt_10.19_104 = vect_patt_8.17_98 | vect_patt_19.18_103;
_108 = vect_patt_10.19_104 != { 0, 0 };
vect_patt_7.20_109 = VEC_COND_EXPR <_108, { 1, 1 }, { 0, 0 }>;
where the _108/_109 defs are really redundant. VRP2 is then the first
pass folding every stmt I think and it transforms this to
_97 = vect__4.15_91 == { 0, 0 };
_102 = vect__5.16_93 != { 0, 0 };
_108 = VEC_COND_EXPR <_97, { -1, -1 }, _102>;
vect_patt_7.20_109 = VEC_COND_EXPR <_108, { 1, 1 }, { 0, 0 }>;
I think this is matching
(simplify
(op (vec_cond:s @0 @1 @2) @3)
(vec_cond @0 (op! @1 @3) (op! @2 @3)))
but since this changes the type of the vec_cond it has to verify it's
still supported.
[Bug tree-optimization/114074] [11/12/13/14 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r8-343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The #c2 testcase with -O2 -Dnoipa=noinline,noclone bisects to either r0-119678-g1a7de2015dfb81f40015a95be98abe50ad7382f0 or r0-119679-g053223551fd7253097117744fcafccd28c8941c0 (r0-119674 works fine, r0-119679 doesn't and I don't have anything in between in the seed, but other commits are go or arm or lra, while this clearly goes wrong during ivcanon pass, where the loop is turned into a single iteration non-loop).
[Bug target/108120] [11/12 Regression] ICE: in extract_insn, at recog.cc:2791 (on ARM with -mfpu=neon -freciprocal-math -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120 Richard Earnshaw changed: What|Removed |Added Summary|[11/12/13 Regression] ICE: |[11/12 Regression] ICE: in |in extract_insn, at |extract_insn, at |recog.cc:2791 (on ARM with |recog.cc:2791 (on ARM with |-mfpu=neon |-mfpu=neon |-freciprocal-math -O3) |-freciprocal-math -O3) Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug middle-end/114070] [12/13/13 regression] ICE when building git-2.43.2 with -mcpu=niagara4 -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114070
--- Comment #5 from Richard Biener ---
Further reduced:
int unresolved(unsigned dirmask, unsigned mask, int *unresolved_n)
{
for (int i = 0; i < 1024; i++) {
mask |= 1;
if (!unresolved_n[i] || unresolved_n[i] & 7)
dirmask |= 1;
}
return (dirmask == mask);
}
[Bug target/108120] [11/12/13 Regression] ICE: in extract_insn, at recog.cc:2791 (on ARM with -mfpu=neon -freciprocal-math -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:f78d1b9c26c2def0e9c54610e73e21f91b5eb05b commit r13-8359-gf78d1b9c26c2def0e9c54610e73e21f91b5eb05b Author: Richard Earnshaw Date: Thu Feb 22 16:47:20 2024 + arm: fix ICE with vectorized reciprocal division [PR108120] The expand pattern for reciprocal division was enabled for all math optimization modes, but the patterns it was generating were not enabled unless -funsafe-math-optimizations were enabled, this leads to an ICE when the pattern we generate cannot be recognized. Fixed by only enabling vector division when doing unsafe math. gcc: PR target/108120 * config/arm/neon.md (div3): Rename from div3. Gate with ARM_HAVE_NEON__ARITH. gcc/testsuite: PR target/108120 * gcc.target/arm/neon-recip-div-1.c: New file. (cherry picked from commit 016c4eed368b80a97101f6156ed99e4c5474fbb7)
[Bug tree-optimization/114075] [14 Regression] s390x miscompilation since r14-322
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114075 --- Comment #3 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #1) > In r14-321 this wasn't vectorized, in r14-322 it is with vf 2, but the > floating point addition is performed in some weird unsigned long operation > instead: > _14 = VIEW_CONVERT_EXPR(vect__17.11_42); > _32 = VIEW_CONVERT_EXPR(vect__18.12_29); > _35 = _14 ^ _32; > _34 = _32 & 9223372034707292159; > _33 = _14 & 9223372034707292159; > _51 = _35 & 9223372039002259456; > _52 = _33 + _34; > _53 = _52 ^ _51; > _54 = VIEW_CONVERT_EXPR(_53); > _19 = _17 + _18; > MEM [(float *)&D.2632] = _54; > The involved constants are 0x7fff7fff and 0x80008000. OT, wouldn't it be cheaper to use 0x7fff and 0x8000 constants instead, i.e. for the MSB just use normal addition/subtraction behavior, there we don't need to be afraid of overflow into another emulated element? Though, maybe 0x7f7f7f7f7f7f7f7f and 0x8080808080808080 are cheaper than 0xff7f7f7f7f7f7f7f and 0x0080808080808080.
