[Bug c++/115902] [14/15 Regression] Can't call immediate function within "if consteval" when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115902 Jonathan Wakely changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- It was introduced by r14-4140: c++: Move consteval folding to cp_fold_r
[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #12 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:44c9403ed1833ae71a59e84f9e37af3182be0df5
commit r15-2026-g44c9403ed1833ae71a59e84f9e37af3182be0df5
Author: Alejandro Colomar
Date: Sat Jun 29 15:10:43 2024 +0200
c, objc: Add -Wunterminated-string-initialization
Warn about the following:
char s[3] = "foo";
Initializing a char array with a string literal of the same length as
the size of the array is usually a mistake. Rarely is the case where
one wants to create a non-terminated character sequence from a string
literal.
In some cases, for writing faster code, one may want to use arrays
instead of pointers, since that removes the need for storing an array of
pointers apart from the strings themselves.
char *log_levels[] = { "info", "warning", "err" };
vs.
char log_levels[][7] = { "info", "warning", "err" };
This forces the programmer to specify a size, which might change if a
new entry is later added. Having no way to enforce null termination is
very dangerous, however, so it is useful to have a warning for this, so
that the compiler can make sure that the programmer didn't make any
mistakes. This warning catches the bug above, so that the programmer
will be able to fix it and write:
char log_levels[][8] = { "info", "warning", "err" };
This warning already existed as part of -Wc++-compat, but this patch
allows enabling it separately. It is also included in -Wextra, since
it may not always be desired (when unterminated character sequences are
wanted), but it's likely to be desired in most cases.
Since Wc++-compat now includes this warning, the test has to be modified
to expect the text of the new warning too, in .
Link: https://lists.gnu.org/archive/html/groff/2022-11/msg00059.html
Link: https://lists.gnu.org/archive/html/groff/2022-11/msg00063.html
Link:
https://inbox.sourceware.org/gcc/36da94eb-1cac-5ae8-7fea-ec66160cf...@gmail.com/T/
PR c/115185
gcc/c-family/ChangeLog:
* c.opt: Add -Wunterminated-string-initialization.
gcc/c/ChangeLog:
* c-typeck.cc (digest_init): Separate warnings about character
arrays being initialized as unterminated character sequences
with string literals, from -Wc++-compat, into a new warning,
-Wunterminated-string-initialization.
gcc/ChangeLog:
* doc/invoke.texi: Document the new
-Wunterminated-string-initialization.
gcc/testsuite/ChangeLog:
* gcc.dg/Wcxx-compat-14.c: Adapt the test to match the new text
of the warning, which doesn't say anything about C++ anymore.
* gcc.dg/Wunterminated-string-initialization.c: New test.
Acked-by: Doug McIlroy
Acked-by: Mike Stump
Reviewed-by: Sandra Loosemore
Reviewed-by: Martin Uecker
Signed-off-by: Alejandro Colomar
Reviewed-by: Marek Polacek
[Bug rtl-optimization/115049] [14/15 Regression] Silent severe miscompilation around inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049 --- Comment #9 from LIU Hao --- Created attachment 58656 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58656&action=edit reduced testcase After spending four days on this, I have reduced a testcase. `./test.sh` should reproduce the segfault. The bug exists around the initialization of a global variable in 'file2.cpp': ``` auto e = new std::discard_block_engine< int >; ``` We compile this file: ``` g++ -O2 -S -masm=intel file2.cpp ``` which produces ``` call"_Znwy" # %rax = ::operator new mov rcx, QWORD PTR "e"[rip] # %rcx = &e mov r10, rax # %r10 = %rax call"_ZNSt20discard_block_engineIiEclEv" # std::discard_block_engine::operator()(%rcx) # -> `this` is passed via %rcx. mov QWORD PTR "d"[rip], r10 # d = %r10 # -> BUG. %r10 has been clobbered by the above call # and now contains a garbage value. mov DWORD PTR [r10], eax # *(DWORD*)%r10 = %eax # -> this faults. ```
[Bug rtl-optimization/115049] [14/15 Regression] Silent severe miscompilation around inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049 --- Comment #10 from LIU Hao --- (In reply to LIU Hao from comment #9) > The bug exists around the initialization of a global variable in 'file2.cpp': This is incorrect. The argument to `operator new` is `4` so the bug happens for initialization of `d`, not `e`: ``` auto e = new std::discard_block_engine< int >; auto d = new int((*e)()); ```
[Bug rtl-optimization/115876] ext-dce.cc has ubsan issues; shifting negative values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876 --- Comment #4 from Andreas Schwab --- This breaks build for m68k: libtool: compile: /daten/aranym/gcc/test/Build/./gcc/xgcc -shared-libgcc -B/daten/aranym/gcc/test/Build/./gcc -nostdinc++ -L/daten/aranym/gcc/test/Build/m68k-linux/libstdc++-v3/src -L/daten/aranym/gcc/test/Build/m68k-linux/libstdc++-v3/src/.libs -L/daten/aranym/gcc/test/Build/m68k-linux/libstdc++-v3/libsupc++/.libs -B/daten/cross/m68k-linux/m68k-linux/bin/ -B/daten/cross/m68k-linux/m68k-linux/lib/ -isystem /daten/cross/m68k-linux/m68k-linux/include -isystem /daten/cross/m68k-linux/m68k-linux/sys-include -I/daten/aranym/gcc/test/libstdc++-v3/../libgcc -I/daten/aranym/gcc/test/Build/m68k-linux/libstdc++-v3/include/m68k-linux -I/daten/aranym/gcc/test/Build/m68k-linux/libstdc++-v3/include -I/daten/aranym/gcc/test/libstdc++-v3/libsupc++ -std=gnu++17 -nostdinc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=fs_path.lo -fimplicit-templates -g -O2 -D_GNU_SOURCE -c ../../../../../libstdc++-v3/src/c++17/fs_path.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o fs_path.o during RTL pass: reload ../../../../../libstdc++-v3/src/c++17/floating_from_chars.cc: In function ‘std::from_chars_result std::from_chars(const char*, const char*, double&, chars_format)’: ../../../../../libstdc++-v3/src/c++17/floating_from_chars.cc:1254:1: internal compiler error: Segmentation fault 1254 | } | ^ operands_match_p (x=, y=0x728671f8) at ../../gcc/reload.cc:2252 2252j += hard_regno_nregs (j, ymode) - 1; (gdb) p x $1 = (gdb) p y $2 = (rtx) 0x728671f8 (gdb) pr (subreg:DI (reg:SI 0 %d0 [orig:116 _213 ] [116]) 0) (gdb) p j $3 = -1
[Bug rtl-optimization/115876] ext-dce.cc has ubsan issues; shifting negative values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876 --- Comment #5 from Andreas Schwab --- Note that the return type of carry_backpropagate should be unsigned as well, but that does not fix the crash.
[Bug rtl-optimization/115876] ext-dce.cc has ubsan issues; shifting negative values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876 --- Comment #6 from Andreas Schwab --- Probably that broke the sign extensions in carry_backpropagate.
[Bug c++/102609] [C++23] P0847R7 - Deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609 --- Comment #30 from Gašper Ažman --- I don't really understand what you meant by "they have corresponding object parameters" - you mean that the object parameters are equal in both constraint and type? "Corresponding" to my recollection is only used for argument-to-parameter correspondence, but I could be wrong.
[Bug rtl-optimization/115876] ext-dce.cc has ubsan issues; shifting negative values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876 --- Comment #7 from Andreas Schwab --- It broke the ASHIFT case. -return mask >> INTVAL (XEXP (x, 1)); +return (HOST_WIDE_INT)mask >> INTVAL (XEXP (x, 1));
[Bug c++/115914] SIGSEGV when std::generator co_yield different ranges of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115914 --- Comment #2 from 康桓瑋 --- (In reply to Andrew Pinski from comment #1) > I suspect this is a dup of bug 113460. Definitely.
[Bug c++/115915] New: gcc fails to detect invalid friend declaration of classes in different namespaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115915
Bug ID: 115915
Summary: gcc fails to detect invalid friend declaration of
classes in different namespaces
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rush102333 at gmail dot com
Target Milestone: ---
Please take a look at the following code:
~~~
namespace std_1 {
template struct extent{};
}
using namespace std_1;
struct S {
friend class extent;
};
~~~
The statement "friend class extent" in line 9 is syntactically invalid. Because
"extent" is a template class, the template argument value of this class must be
specified when it is declared as a friend class of other classes. For example,
"friend class extent".
However, GCC seems to ignore that rule and accept the code. This only happens
when "extent" is declared in an independent namespace. Clang rejects that code
by giving the following message:
:9:23: error: template 'extent' cannot be referenced with the 'class'
specifier
9 | friend class extent;};
| ^
:2:28: note: declared here
2 | template struct extent;
|^
1 error generated.
MSVC also rejects the code, but EDG and ICC seem to accept it.
https://godbolt.org/z/xMbvaf768
Without namespace:
https://godbolt.org/z/evdEWaqT7
[Bug rtl-optimization/115049] [14/15 Regression] Silent severe miscompilation around inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049 --- Comment #11 from LIU Hao --- The function template `std::discard_block_engine::operator()` is instantiated in both translation units. The two specializations use different sets of caller-saved registers. Specifically, the specialization in 'file1.cpp' uses the `r10` register, but the other one in 'file2.cpp' doesn't. GCC assumes that `r10` will not be clobbered by the call in 'file2.cpp', but due to COMDAT, after linking it's the specialization in 'file1.cpp' that is called, where `r10` is really clobbered, which causes a fault.
[Bug middle-end/115916] New: [15 Regression] wrong code on highway-1.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115916
Bug ID: 115916
Summary: [15 Regression] wrong code on highway-1.2.0
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Seemingly a recent regression.
On gcc-master r15-2026-g44c9403ed1833a highway-1.2.0 testsuite fails as:
The following tests FAILED:
1190 -
HwyShuffle4TestGroup/HwyShuffle4Test.TestAllPer4LaneBlockShuffle/EMU128 #
GetParam() = 2305843009213693952 (Subprocess aborted)
Here is the minimized version extracted out of original example:
// $ cat shuffle4_test.cc
#include
#include
struct ve {
ve() = default;
ve(const ve&) = default;
ve& operator=(const ve&) = default;
// note that the code usually uses the first half of this array
uint8_t raw[16] = {};
};
static ve First8_(void) {
ve m;
__builtin_memset(m.raw, 0xff, 8);
return m;
}
static ve And_(ve a, ve b) {
ve au;
__builtin_memcpy(au.raw, a.raw, 16);
for (size_t i = 0; i < 8; ++i) {
au.raw[i] &= b.raw[i];
}
return au;
}
__attribute__((noipa, optimize(0)))
static void vec_assert(ve a) {
if (a.raw[6] != 0x06 && a.raw[6] != 0x07)
__builtin_trap();
}
static ve Reverse4_(ve v) {
ve ret;
for (size_t i = 0; i < 8; i += 4) {
ret.raw[i + 0] = v.raw[i + 3];
ret.raw[i + 1] = v.raw[i + 2];
ret.raw[i + 2] = v.raw[i + 1];
ret.raw[i + 3] = v.raw[i + 0];
}
return ret;
}
static ve DupEven_(ve v) {
for (size_t i = 0; i < 8; i += 2) {
v.raw[i + 1] = v.raw[i];
}
return v;
}
template
ve Per4LaneBlockShuffle_(ve v) {
if (b) {
return Reverse4_(v);
} else {
return DupEven_(v);
}
}
template
static inline __attribute__((always_inline)) void
DoTestPer4LaneBlkShuffle(const ve v) {
ve actual = Per4LaneBlockShuffle_(v);
const auto valid_lanes_mask = First8_();
ve actual_masked = And_(valid_lanes_mask, actual);
vec_assert(actual_masked);
}
static void DoTestPer4LaneBlkShuffles(const ve v) {
alignas(128) uint8_t src_lanes[8];
__builtin_memcpy(src_lanes, v.raw, 8);
// need both, hm
DoTestPer4LaneBlkShuffle(v);
DoTestPer4LaneBlkShuffle(v);
}
__attribute__((noipa, optimize(0)))
static void bug(void) {
uint8_t iv[8] = {1,2,3,4,5,6,7,8};
ve v;
__builtin_memcpy(v.raw, iv, 8);
DoTestPer4LaneBlkShuffles(v);
}
int main(void) {
bug();
}
Bad:
$ gcc/xg++ -Bgcc shuffle4_test.cc -O3 -o bug && ./bug
Illegal instruction (core dumped)
Ok:
$ gcc/xg++ -Bgcc shuffle4_test.cc -O2 -o bug && ./bug
$ gcc/xg++ -Bgcc -v
Reading specs from gcc/specs
COLLECT_GCC=gcc/xg++
COLLECT_LTO_WRAPPER=gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--disable-bootstrap --disable-lto --disable-libsanitizer
--disable-libstdcxx-pch --enable-languages=c,c++ --disable-libgomp
--disable-libquadmath --disable-libvtv CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0'
LDFLAGS='-O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240714 (experimental) (GCC)
[Bug libstdc++/113460] Segfault in __builtin_coro_destroy when using std::generator to concate ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113460
--- Comment #2 from Arsen Arsenović ---
this is a double-free it would seem.
but, the following works:
#include
#include
#include
#include
using namespace std;
template
[[nodiscard]] auto
concat(Range1&& range1, Range2&& range2) -> generator
{
co_yield ranges::elements_of(range1);
co_yield ranges::elements_of(range2);
}
auto
main() -> int
{
auto const numbers1 = array{0};
auto const numbers2 = vector{0};
for (auto const _: concat(numbers1, numbers2) ) {}
}
... which is quite intriguing.. is this equivalent to the first example?
[Bug middle-end/115916] [15 Regression] wrong code on highway-1.2.0 since r15-2011-ga6f551d079de1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115916 Sergei Trofimovich changed: What|Removed |Added CC||law at gcc dot gnu.org Summary|[15 Regression] wrong code |[15 Regression] wrong code |on highway-1.2.0|on highway-1.2.0 since ||r15-2011-ga6f551d079de1d --- Comment #1 from Sergei Trofimovich --- Bisect says r15-2011-ga6f551d079de1d introduced it: commit a6f551d079de1d151b272bcdd3d42316857c9d4e Author: Jeff Law Date: Fri Jul 12 13:11:33 2024 -0600 [PR rtl-optimization/115876] Fix one of two ubsan reported issues in new ext-dce.cc code
[Bug middle-end/115916] [15 Regression] wrong code on highway-1.2.0 since r15-2011-ga6f551d079de1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115916 --- Comment #2 from Andreas Schwab --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876#c7 It broke the ASHIFT case. -return mask >> INTVAL (XEXP (x, 1)); +return (HOST_WIDE_INT)mask >> INTVAL (XEXP (x, 1));
[Bug ada/115917] New: GNAT fails to bootstrap with LTO and -Werror=lto-type-mismatch due to C_Version_String and gnat_version_string on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115917 Bug ID: 115917 Summary: GNAT fails to bootstrap with LTO and -Werror=lto-type-mismatch due to C_Version_String and gnat_version_string on x86_64-pc-linux-gnu Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: arsen at gcc dot gnu.org CC: dkm at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu Created attachment 58657 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58657&action=edit possible (regression untested, but build tested) fix $summary I've been using the attached patch as a workaround (or potentially a fix), but I haven't regression tested it or sent it upstream yet. ../../gcc/gcc/ada/gnatvsn.adb:51:4: warning: type of ‘gnatvsn__c_version_string’ does not match original declaration [-Wlto-type-mismatch] 51 |C_Version_String : char_array (0 .. Ver_Len_Max - 1); |^ ../../gcc/gcc/ada/version.c:34:6: note: array types have different bounds 34 | char gnat_version_string[] = version_string; | ^ ../../gcc/gcc/ada/version.c:34:6: note: ‘gnat_version_string’ was previously declared here
[Bug ada/115918] New: Bootstrap failure in GNAT with --with-build-config=bootstrap-lto --enable-languages=c,ada,c++,lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115918 Bug ID: 115918 Summary: Bootstrap failure in GNAT with --with-build-config=bootstrap-lto --enable-languages=c,ada,c++,lto Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: arsen at gcc dot gnu.org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 58658 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58658&action=edit fail.log current trunk (r15-2026-g44c9403ed1833a) fails to bootstrap w/ Ada and bootstrap-lto enabled: ~/gcc/scratch-build 1 $ grep 'internal compiler error:' fail.log ../../gcc/gcc/ada/bindo-elaborators.adb:1285:7: internal compiler error: in fold_stmt, at gimple-range-fold.cc:701 ../../gcc/gcc/ada/table.adb:164:7: internal compiler error: in fold_stmt, at gimple-range-fold.cc:701 ../../gcc/gcc/ada/bindo-elaborators.adb:704:7: internal compiler error: in fold_stmt, at gimple-range-fold.cc:701 ada/g-graphs.adb:986:10: internal compiler error: in fold_stmt, at gimple-range-fold.cc:701 ../../gcc/gcc/ada/sinput.adb:541:4: internal compiler error: in fold_stmt, at gimple-range-fold.cc:701 ../../gcc/gcc/ada/fmap.adb:175:4: internal compiler error: in fold_stmt, at gimple-range-fold.cc:701 ~/gcc/scratch-build$ ./config.status --config '--with-build-config=bootstrap-lto' '--enable-languages=c,ada,c++,lto' more complete log attached. no special setup was required host gcc: gcc (Gentoo Hardened 14.1.1_p20240706 p3) 14.1.1 20240706 host gnat: GNAT 14.1.1 20240706 interestingly, all the files that are failing are .adb files. this could be because there is an LTO bug that only gets noticed or GNAT, or because GNAT does something to cause LTO to fail. unsure which one is the case I could not reproduce this for gcc-14 20240706
[Bug ada/115918] Bootstrap failure in GNAT with --with-build-config=bootstrap-lto --enable-languages=c,ada,c++,lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115918 --- Comment #1 from Andreas Schwab --- Does the pseudo patch in PR115876#c7 help?
[Bug c++/115919] New: ICE: in tsubst_expr, at cp/pt.cc:20300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115919
Bug ID: 115919
Summary: ICE: in tsubst_expr, at cp/pt.cc:20300
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
Target: x86_64
***
The compiler produces an internal error during tsubst_expr when compiling the
provided code with the specified options.
The issue can also be reproduced on Compiler Explorer.
***
OS and Platform:
# uname -a
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/root/gdbtest/gcc/gcc-15/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /root/gdbtest/gcc/obj/../gcc/configure
--prefix=/root/gdbtest/gcc/gcc-15 --enable-languages=c,c++,fortran,go
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240509 (experimental) (GCC)
***
Program:
# cat pom.ii
template
class A
{
public:
static double const VAL = 0.5;
enum
{
COS = (int)(A::VAL)
};
};
int main()
{
A<5>::COS;
return 0;
}
***
Command Lines:
# g++ pom.ii -O2 -Wall -Wextra -pedantic -std=c++17 -fno-exceptions -fno-rtti
-fstrict-aliasing -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align
-Woverloaded-virtual -Wconversion -Wsign-conversion -Wduplicated-cond
-Wduplicated-branches -Wlogical-op -Wnull-dereference -Wuseless-cast
-Wdouble-promotion -Wformat=2 -o pom.o
pom.cpp:5:25: error: ‘constexpr’ needed for in-class initialization of static
data member ‘const double A::VAL’ of non-integral type [-fpermissive]
pom.cpp:9:20: warning: use of old-style cast to ‘int’ [-Wold-style-cast]
pom.cpp: In instantiation of ‘class A<5>’:
pom.cpp:15:9: required from here
pom.cpp:5:25: error: ‘constexpr’ needed for in-class initialization of static
data member ‘const double A<5>::VAL’ of non-integral type [-fpermissive]
pom.cpp:9:8: internal compiler error: in tsubst_expr, at cp/pt.cc:20306
0x82df47 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:20306
0xcdf0fe tsubst_enum
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:27699
0xcdf0fe lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:10496
0xcd2cd0 tsubst(tree_node*, tree_node*, int, tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:16265
0xccf2d4 tsubst_decl
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:15435
0xcef0d0 instantiate_class_template(tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:12572
0xd43e90 complete_type(tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/typeck.cc:138
0xc6bc3a cp_parser_nested_name_specifier_opt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:7271
0xc7a7b7 cp_parser_simple_type_specifier
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:20576
0xc53411 cp_parser_type_specifier
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:20227
0xc551ed cp_parser_decl_specifier_seq
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:16675
0xc56588 cp_parser_simple_declaration
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:15831
0xc7cb60 cp_parser_declaration_statement
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:14944
0xc84b7e cp_parser_statement
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:12897
0xc59807 cp_parser_statement_seq_opt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:13427
0xc59a2f cp_parser_compound_statement
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:13281
0xc7ccd5 cp_parser_function_body
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:26072
0xc7ccd5 cp_parser_ctor_initializer_opt_and_function_body
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:26123
0xc8241e cp_parser_function_definition_after_declarator
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:32903
0xc835be cp_parser_function_definition_from_specifiers_and_declarator
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:32820
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/115920] New: ICE: in tree_to_poly_int64, at tree.cc:3319
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115920
Bug ID: 115920
Summary: ICE: in tree_to_poly_int64, at tree.cc:3319
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
Target: x86_64
***
The compiler produces an internal error during tree_to_poly_int64 when
compiling the provided code with the specified options.
The issue can also be reproduced on Compiler Explorer.
***
OS and Platform:
# uname -a
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/root/gdbtest/gcc/gcc-15/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /root/gdbtest/gcc/obj/../gcc/configure
--prefix=/root/gdbtest/gcc/gcc-15 --enable-languages=c,c++,fortran,go
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240509 (experimental) (GCC)
***
Program:
# cat source_code_1.c
struct s {
int i;
char c[];
};
const struct s s = { .c = "0", };
const struct s *const r = &(constexpr struct s) { .c = "1", };
const struct s *const t = &(static struct s) { .c = "2", };
size_t ice(void)
{
return __builtin_object_size(t, 1);
}
***
Command Lines:
# gcc source_code_1.c -O2 -Wall -Wextra -pedantic -std=c99 -fstrict-aliasing
-Wshadow -Wconversion -Wsign-conversion -Wcast-align -Wformat=2
-Wnull-dereference -Wstrict-overflow=5 -Wdouble-promotion -Wduplicated-cond
-Wduplicated-branches -Wlogical-op -Wuseless-cast -Wno-gnu-anonymous-struct
-Wno-non-standard-layout -Wno-variadic-macros -o source_code_1.o
source_code_1.c:7:27: warning: initialization of a flexible array member
[-Wpedantic]
7 | const struct s s = { .c = "0", };
| ^~~
source_code_1.c:7:27: note: (near initialization for ‘s.c’)
source_code_1.c:7:14: warning: initialization of a flexible array member
[-Wpedantic]
7 | const struct s s = { .c = "0", };
| ^
source_code_1.c:7:14: note: (near initialization for ‘s’)
source_code_1.c:8:29: error: ‘constexpr’ undeclared here (not in a function)
8 | const struct s *const r = &(constexpr struct s) { .c = "1", };
| ^
source_code_1.c:8:38: error: expected ‘)’ before ‘struct’
8 | const struct s *const r = &(constexpr struct s) { .c = "1", };
|~ ^~~
| )
source_code_1.c:8:49: error: expected ‘,’ or ‘;’ before ‘{’ token
8 | const struct s *const r = &(constexpr struct s) { .c = "1", };
| ^
source_code_1.c:8:62: warning: ISO C does not allow extra ‘;’ outside of a
function [-Wpedantic]
8 | const struct s *const r = &(constexpr struct s) { .c = "1", };
| ^
source_code_1.c:9:53: warning: initialization of a flexible array member
[-Wpedantic]
9 | const struct s *const t = &(static struct s) { .c = "2", };
| ^~~
source_code_1.c:9:53: note: (near initialization for ‘(anonymous).c’)
source_code_1.c:9:43: warning: initialization of a flexible array member
[-Wpedantic]
9 | const struct s *const t = &(static struct s) { .c = "2", };
| ^
source_code_1.c:9:43: note: (near initialization for ‘(anonymous)’)
source_code_1.c:9:46: warning: ISO C forbids storage class specifiers in
compound literals before C23 [-Wpedantic]
9 | const struct s *const t = &(static struct s) { .c = "2", };
| ^
source_code_1.c:11:1: error: unknown type name ‘size_t’
11 | size_t ice(void)
| ^~
source_code_1.c:1:1: note: ‘size_t’ is defined in header ‘’; this is
probably fixable by adding ‘#include ’
+++ |+#include
1 |
source_code_1.c: In function ‘ice’:
source_code_1.c:13:12: warning: conversion from ‘long unsigned int’ to ‘int’
may change value [-Wconversion]
13 | return __builtin_object_size(t, 1);
|^~~
source_code_1.c:13:12: internal compiler error: in tree_to_poly_int64, at
tree.cc:3313
0x8bd846 tree_to_poly_int64(tree_node const*)
/root/gdbtest/gcc/obj/../g
[Bug c++/115914] SIGSEGV when std::generator co_yield different ranges of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115914 Arsen Arsenović changed: What|Removed |Added CC||arsen at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Arsen Arsenović --- yeah, think so too (removing the fold from this one also results in there being no bug) *** This bug has been marked as a duplicate of bug 113460 ***
[Bug libstdc++/113460] Segfault in __builtin_coro_destroy when using std::generator to concate ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113460 Arsen Arsenović changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #3 from Arsen Arsenović --- *** Bug 115914 has been marked as a duplicate of this bug. ***
[Bug libstdc++/113460] Segfault in __builtin_coro_destroy when using std::generator to concate ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113460
--- Comment #4 from Arsen Arsenović ---
actually, it seems to be the comma, not the fold; the following also fails:
#include
#include
#include
#include
using namespace std;
template
[[nodiscard]] auto
concat(Range1&& range1, Range2&& range2) -> generator
{
co_yield ranges::elements_of(range1), // <-
co_yield ranges::elements_of(range2);
}
auto
main() -> int
{
auto const numbers1 = array{0};
auto const numbers2 = vector{0};
for (auto const _: concat(numbers1, numbers2) ) {}
}
[Bug rtl-optimization/115912] [15 regression] Harfbuzz testsuite fails (mvar_partial_instance test) since r15-1901-g98914f9eba5f19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #2 from Sam James ---
Surrounding this template from src/hb-open-type.hh w/ optimize("O0") cures it:
```
template
struct HBFixed : Type
{
static constexpr float shift = (float) (1 << fraction_bits);
static_assert (Type::static_size * 8 > fraction_bits, "");
operator signed () const = delete;
operator unsigned () const = delete;
explicit operator float () const { return to_float (); }
typename Type::type to_int () const { return Type::v; }
void set_int (typename Type::type i ) { Type::v = i; }
float to_float (float offset = 0) const { return ((int32_t) Type::v +
offset) / shift; }
void set_float (float f) { Type::v = roundf (f * shift); }
public:
DEFINE_SIZE_STATIC (Type::static_size);
};
```
[Bug target/115921] New: Missed optimization: and->ashift might be cheaper than ashift->and on typical RISC targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115921
Bug ID: 115921
Summary: Missed optimization: and->ashift might be cheaper than
ashift->and on typical RISC targets
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lis8215 at gmail dot com
Target Milestone: ---
At the moment GCC prefers 'ashift first' flavor pattern.
However, it might ends up in emitting expensive constants for subsequent AND
operation.
It might be cheaper to do AND operation first, since there's a chance to match
variant of AND operation which accepts immediate.
Example:
target_wide_uint_t test_ashift_and (target_wide_uint_t x)
{
return (x & 0x3f) << 12;
}
godbolt results are the following:
[Xtensa ESP32-S3 gcc 12.2.0 (-O3)]
test_ashift_and:
entry sp, 32
l32ra8, .LC0
sllia2, a2, 12
and a2, a2, a8
retw.n
; missed constant in output
[SPARC gcc 14.1.0 (-O3)]
test_ashift_and:
sethi %hi(258048), %g1
sll %o0, 12, %o0
jmp %o7+8
and%o0, %g1, %o0
[sh gcc 14.1.0 (-O3)]
_test_ashift_and:
mov r4,r0
shll2 r0
extu.b r0,r0
shll8 r0
rts
shll2 r0
[s390x gcc 14.1.0 (-O3)]
test_ashift_and:
larl%r5,.L4
sllg%r2,%r2,12
ng %r2,.L5-.L4(%r5)
br %r14
.L4:
.L5:
.quad 258048
[RISC-V (64-bit) gcc 14.1.0 (-O3)]
test_ashift_and:
li a5,258048
sllia0,a0,12
and a0,a0,a5
ret
[mips (el) gcc 14.1.0 (-O3)]
test_ashift_and:
li $2,196608 # 0x3
sll $4,$4,12
ori $2,$2,0xf000
jr $31
and $2,$4,$2
[mips64 (el) gcc 14.1.0 (-O3)]
test_ashift_and:
li $2,196608 # 0x3
dsll$4,$4,12
ori $2,$2,0xf000
jr $31
and $2,$4,$2
[loongarch64 gcc 14.1.0 (-O3)]
test_ashift_and:
lu12i.w $r12,258048>>12 # 0x3f000
slli.d $r4,$r4,12
and $r4,$r4,$r12
jr $r1
however, shifting to 33 got:
[mips64 (el) gcc 14.1.0 (-O3, ashift to 33)]
test_ashift_and:
andi$2,$4,0x3f
jr $31
dsll$2,$2,33
[SPARC64 gcc 14.1.0 (-O3, ashift to 33)]:
test_ashift_and:
and %o0, 63, %o0
jmp %o7+8
sllx %o0, 33, %o0
It seems like RISC-V (32-bit) is aware of that in trunk (14.1.0 won't):
[RISC-V (32-bit) gcc (trunk) (-O3)]
test_ashift_and:
andia0,a0,63
sllia0,a0,12
ret
while RV64 is not so good.
While this situation appears rarely in general, it appears 85 times in pcre2
matching routine, which is ~2% of the overall routine's code size (on mips32).
Also, it might be profitable to match any bitwise operator here: e.g. OR,XOR in
addition to AND.
[Bug target/115922] New: Missed optimization: MIPS: clear bit 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115922
Bug ID: 115922
Summary: Missed optimization: MIPS: clear bit 15
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lis8215 at gmail dot com
Target Milestone: ---
Created attachment 58659
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58659&action=edit
silly patch designed for mips32 mips32r2
simple testcase:
# define MASK (~(0x8000U))
host_width_type_t test(host_width_type_t x)
{
return x & MASK;
}
Now for clearing bit 15 GCC emits something like:
test:
li $2,-65536# 0x
addiu $2,$2,32767 # 0x7fff
and $2,$4,$2
while it's cheaper to use:
ori $2,$2,32768 #0x8000
xori$2,$2,32768
any mask in range ~0x8000 .. ~0xfffe seems profitable, even for MIPS32r2+
where INS instruction can be used to clear group of bits.
Such pattern appears rarely and mostly in low level software e.g. linux kernel.
for linux kernel it shows ~40 matches per million of insns.
Might also be profitable for RISC-V, not tested.
[Bug ada/115918] Bootstrap failure in GNAT with --with-build-config=bootstrap-lto --enable-languages=c,ada,c++,lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115918 --- Comment #2 from Arsen Arsenović --- Created attachment 58660 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58660&action=edit fail.log but with the patchlet applied No, at least not entirely.
[Bug rtl-optimization/115877] [15 Regression] wrong code at -Os (missing zero extension)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877 Andreas Schwab changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #3 from Andreas Schwab --- dup *** This bug has been marked as a duplicate of bug 115916 ***
[Bug middle-end/115916] [15 Regression] wrong code on highway-1.2.0 since r15-2011-ga6f551d079de1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115916 Andreas Schwab changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #3 from Andreas Schwab --- *** Bug 115877 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/115912] [15 regression] Harfbuzz testsuite fails (mvar_partial_instance test) since r15-1901-g98914f9eba5f19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912 Andreas Schwab changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andreas Schwab --- dup *** This bug has been marked as a duplicate of bug 115916 ***
[Bug middle-end/115916] [15 Regression] wrong code on highway-1.2.0 since r15-2011-ga6f551d079de1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115916 Andreas Schwab changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #4 from Andreas Schwab --- *** Bug 115912 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/115877] [15 Regression] wrong code at -Os (missing zero extension)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877 --- Comment #4 from Sam James --- (In reply to Andreas Schwab from comment #3) > dup > > *** This bug has been marked as a duplicate of bug 115916 *** This came first and it has a smaller testcase? The other is fine too, of course though.
[Bug c/115920] ICE: in tree_to_poly_int64, at tree.cc:3319
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115920 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 109828 ***
[Bug c/109828] [13/14/15 Regression] static compound literal with flexible array in initializer leads to invalid size and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828 Andrew Pinski changed: What|Removed |Added CC||iamanonymous.cs at gmail dot com --- Comment #14 from Andrew Pinski --- *** Bug 115920 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/115912] [15 regression] Harfbuzz testsuite fails (mvar_partial_instance test) since r15-1901-g98914f9eba5f19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|NEW Resolution|DUPLICATE |--- Last reconfirmed||2024-07-14 --- Comment #4 from Andrew Pinski --- This is different from bug 115916 .
[Bug c++/115915] gcc fails to detect invalid friend declaration of classes in different namespaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115915 --- Comment #1 from Andrew Pinski --- The question is does that friend is naming `::extent` or is naming `std_1::extent` using the `using namespace` statement. I suspect GCC and EDG think it is `::extent` while clang and MSVC think it is `std_1::extent`.
[Bug c++/115923] New: different diagnostic if using qualified name vs not for missing template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115923
Bug ID: 115923
Summary: different diagnostic if using qualified name vs not
for missing template arguments
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
template struct extent{};
struct extent t;
struct ::extent t1;
```
GCC currently produces:
```
:4:8: error: template argument required for 'struct extent'
4 | struct extent t;
|^~
:5:10: error: invalid use of template-name 'extent' without an argument
list
5 | struct ::extent t1;
| ^~
:2:22: note: 'template > struct extent' declared here
2 | template struct extent{};
| ^~
```
The error messages are correct but they are different and the qualified name
even gives where the definition was originally defined while the non-qualified
one does not. It would be useful if the non-qualified gives the same error
message and where the original definition was.
[Bug c++/115915] gcc fails to detect invalid friend declaration of classes in different namespaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115915 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-07-14 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115923 --- Comment #2 from Andrew Pinski --- Confirmed. Trying with `::extend` causes an error message to be outputted. Related to PR 115923 where different error messages show up with qualified vs non-qualified names even.
[Bug c++/102707] template coroutine generated code failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102707 Arsen Arsenović changed: What|Removed |Added CC||arsen at gcc dot gnu.org --- Comment #2 from Arsen Arsenović --- seems to have been fixed somewhere between 11.1 and 12.1
[Bug other/115705] dubious macro definition ‘__attr_dealloc_fclose’ [-Winvalid-imported-macros]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115705 --- Comment #4 from Dev Dude --- (In reply to Andrew Pinski from comment #3) > Confirmed; suspended. > > We should do a fix includes once this has been fixed in glibc. Any follow up / update on this. The related glibc bug says that should be an easy fix but it doesn't seem to have progressed. Thanks!
[Bug c++/115706] Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 --- Comment #3 from Dev Dude --- Hello, any update on this bug? Has anyone run the script I provided in the prior post for building the module headers? Or can anyone comment on the correct way to build module headers? I can't progress on modules builds. Running the script with no parameters causes stack dump shown on compiling headers execution and random, but re-running the script with parameters 'random' and 'execution' causes them to build without compiler crash. But in any case, the resulting compilation of my project with all the headers, bug 115705, stops modules compilation in any case. So I can't progress module builds with gcc. It would seem easy to confirm at least. Thanks.
[Bug c++/115706] Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 --- Comment #4 from Sam James --- I'd really suggest filing one bug per issue in future. Making it very clear what a specific bug is about and how to reproduce with a standalone attachment is good too (your last issue at least seems to need your project, but not looked properly). Modules are considered to be experimental still and I'd expect someone to look but not immediately.
[Bug other/115705] dubious macro definition ‘__attr_dealloc_fclose’ [-Winvalid-imported-macros]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115705 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #5 from Sam James --- glibc is in freeze in preparation for the next release. You can try submit a patch though if you're motivated, and it sounds like you are.
[Bug c++/115706] Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 --- Comment #5 from Dev Dude --- I'm not sure what's difficult about me posing a question about what the correct way is to build module headers so they all build properly, and also providing my own script to show what I'm doing in absence of knowing the correct way, and pointing out that doesn't work, and why. It doesn't need my own code as it's failing on gcc's own code. It's a case of simply pasting that script in a file and running it, vs, downloading it and running it. But in any case my question wasn't answered, and remains unanswered, but apparently it's hard to paste the script into a file, and easier to write back instead and complain. Ok then. Have it your way. I'll continue to use clang where modules work for me and not help your project. I'm sick of this.
[Bug fortran/99798] ICE when compiling a variant of pr87907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99798 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Mikael Morin : https://gcc.gnu.org/g:c80a7460239037d8cf8426dbb7d03c6ddac09bab commit r14-10420-gc80a7460239037d8cf8426dbb7d03c6ddac09bab Author: Mikael Morin Date: Sun May 12 15:16:23 2024 +0200 fortran: Assume there is no cyclic reference with submodule symbols [PR99798] This prevents a premature release of memory with procedure symbols from submodules, causing random compiler crashes. The problem is a fragile detection of cyclic references, which can match with procedures host-associated from a module in submodules, in cases where it shouldn't. The formal namespace is released, and with it the dummy arguments symbols of the procedure. But there is no cyclic reference, so the procedure symbol itself is not released and remains, with pointers to its dummy arguments now dangling. The fix adds a condition to avoid the case, and refactors to a new predicate by the way. Part of the original condition is also removed, for lack of a reason to keep it. PR fortran/99798 gcc/fortran/ChangeLog: * symbol.cc (gfc_release_symbol): Move the condition guarding the handling cyclic references... (cyclic_reference_break_needed): ... here as a new predicate. Remove superfluous parts. Add a condition preventing any premature release with submodule symbols. gcc/testsuite/ChangeLog: * gfortran.dg/submodule_33.f08: New test. (cherry picked from commit 38d1761c0c94b77a081ccc180d6e039f7a670468)
[Bug c++/105989] Coroutine frame space for temporaries in a co_await expression is not reused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989 Arsen Arsenović changed: What|Removed |Added CC||arsen at gcc dot gnu.org --- Comment #6 from Arsen Arsenović --- hi, thanks for the patch. could you propose it on the ML? patches seldom get noticed here on BZ (see also https://gcc.gnu.org/contribute.html )
[Bug tree-optimization/115924] New: Failure to optimize back and forth shifts of several operands by the same amount with operations in the middle to ands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115924
Bug ID: 115924
Summary: Failure to optimize back and forth shifts of several
operands by the same amount with operations in the
middle to ands
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
int32_t f(int32_t i2, int32_t aa)
{
return ((i2 >> 17) + (aa >> 17)) << 17;
}
int32_t f2(int32_t i2, int32_t aa)
{
return ((i2 & -(1 << 17)) + aa) & -(1 << 17);
}
bool f3(int32_t i2, int32_t aa)
{
return f(i2, aa) == f2(i2, aa);
}
f can be optimized to f2, and consequently f3 to `return true;`. This
transformation is done by LLVM, but not by GCC.
(note: this seems logically generalizable to amounts other than 17, and pretty
much any operation after right shifting the two operands before shifting them
back (e.g. replacing `+` with `-`, `^` or many other more complex operations))
[Bug c++/109682] coroutines: ICE in morph_fn_to_coro on wrong return type for get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109682 Arsen Arsenović changed: What|Removed |Added Last reconfirmed||2024-07-14 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||ice-on-valid-code CC||arsen at gcc dot gnu.org --- Comment #2 from Arsen Arsenović --- GCC presumes get_return_object_on_allocation_failure returns the same type as the get_return_object function. it trips there. (conjecture) I think this is valid and should cause a conversion, but that it was left as a TODO. the standard does not state otherwise and both Clang and MSVC appear to attempt a conversion.
[Bug middle-end/115924] Failure to optimize back and forth shifts of several operands by the same amount with operations in the middle to ands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115924
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |middle-end
--- Comment #1 from Andrew Pinski ---
Note clang falls over when the order is swapped of the addition is swapped:
```
#include
uint32_t f(uint32_t i2, uint32_t aa)
{
return ((i2 >> 17) + (aa >> 17)) << 17;
}
uint32_t f2(uint32_t i2, uint32_t aa)
{
return ((aa & -(1 << 17)) + i2) & -(1 << 17);
}
bool f3(uint32_t i2, uint32_t aa)
{
return f(i2, aa) == f2(i2, aa);
}
```
[Bug middle-end/115924] Failure to optimize back and forth shifts of several operands by the same amount with operations in the middle to ands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115924
--- Comment #2 from Andrew Pinski ---
Note clang also falls over for 3 additions and swapping the order of the
addition just slightly.
```
#include
int32_t f(int32_t i2, int32_t aa, int32_t aa1)
{
return ((i2 >> 17) + (aa >> 17) + (aa1 >> 17)) << 17;
}
int32_t fa(int32_t i2, int32_t aa, int32_t aa1)
{
return ((i2 >> 17) + (aa1 >> 17) + (aa >> 17)) << 17;
}
int32_t f2(int32_t i2, int32_t aa, int32_t aa1)
{
return i2 & -(1 << 17)) + aa) & -(1 << 17)) + aa1) & -(1 << 17);
}
int32_t f2a(int32_t i2, int32_t aa, int32_t aa1)
{
return i2 & -(1 << 17)) + aa1) & -(1 << 17)) + aa) & -(1 << 17);
}
bool f3a(int32_t i2, int32_t aa, int32_t aa1)
{
return f(i2, aa, aa1) == fa(i2, aa, aa1);
}
bool f3(int32_t i2, int32_t aa, int32_t aa1)
{
return f(i2, aa, aa1) == f2a(i2, aa, aa1);
}
```
So the question becomes which is more Canonical rather than anything else.
[Bug tree-optimization/115925] New: wrong code at -O{2,3} with "-fno-thread-jumps" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115925
Bug ID: 115925
Summary: wrong code at -O{2,3} with "-fno-thread-jumps" on
x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a regression from 13.*, and affects 14.1 and the trunk.
Compiler Explorer: https://godbolt.org/z/dThxjfzf3
[521] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240714 (experimental) (GCC)
[522] %
[522] % gcctk -O2 small.c; ./a.out
[523] %
[523] % gcctk -O2 -fno-thread-jumps small.c
[524] % ./a.out
1
[525] % cat small.c
int printf(const char *, ...);
int a, b, c = 1, d = 1, e, g;
char f;
int main() {
int h = 10, i;
j:
if (h < e) {
printf("%d\n", c);
return 0;
}
i = -1;
if (d)
i = h;
h = b = -2;
a = (b ^ i) | (c || f);
if (i <= a)
g = ~i;
if (a > 0)
goto j;
return 0;
}
[Bug middle-end/115924] Failure to optimize back and forth shifts of several operands by the same amount with operations in the middle to ands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115924
--- Comment #3 from Andrew Pinski ---
Note better example:
```
#include
uint32_t f(uint32_t i2, uint32_t aa, uint32_t aa1)
{
return ((i2 >> 17) + (aa >> 17) + (aa1 >> 17)) << 17;
}
uint32_t fa(uint32_t i2, uint32_t aa, uint32_t aa1)
{
return ((i2 >> 17) + (aa1 >> 17) + (aa >> 17)) << 17;
}
uint32_t f2(uint32_t i2, uint32_t aa, uint32_t aa1)
{
return i2 & -(1 << 17)) + aa) & -(1 << 17)) + aa1) & -(1 << 17);
}
uint32_t f2a(uint32_t i2, uint32_t aa, uint32_t aa1)
{
return i2 & -(1 << 17)) + aa1) & -(1 << 17)) + aa) & -(1 << 17);
}
bool f3a(uint32_t i2, uint32_t aa, uint32_t aa1)
{
return f(i2, aa, aa1) == fa(i2, aa, aa1);
}
bool f3(uint32_t i2, uint32_t aa, uint32_t aa1)
{
return f(i2, aa, aa1) == f2a(i2, aa, aa1);
}
```
GCC is able to optimize f3a but clang/LLVM does not.
[Bug tree-optimization/115926] New: wrong code at -O1 with "-fno-tree-fre" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115926
Bug ID: 115926
Summary: wrong code at -O1 with "-fno-tree-fre" on
x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a regression from 11.* and affects 12.* and later.
Compiler Explorer: https://godbolt.org/z/qG1rYens8
[516] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240714 (experimental) (GCC)
[517] %
[517] % gcctk -O1 small.c; ./a.out
[518] %
[518] % gcctk -O1 -fno-tree-fre small.c
[519] % ./a.out
Segmentation fault
[520] %
[520] % cat small.c
struct a {
int b;
} const c;
int d;
void e(const struct a g) { d = 0; }
long f(const struct a g) {
int h;
e(g);
h = g.b;
return g.b;
}
int main() {
f(c);
return 0;
}
[Bug tree-optimization/115927] New: wrong code at -O{2,3} with "-fno-tree-vrp" on x86_64-linux-gnu (nondeterministic behavior)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115927
Bug ID: 115927
Summary: wrong code at -O{2,3} with "-fno-tree-vrp" on
x86_64-linux-gnu (nondeterministic behavior)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression as it doesn't reproduce with 14.1 and
earlier.
Compiler Explorer: https://godbolt.org/z/76naEWj7b
[582] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240714 (experimental) (GCC)
[583] %
[583] % gcctk -O2 small.c
[584] % ./a.out
0
[585] % gcctk -O2 -fno-tree-vrp small.c
[586] % ./a.out
[587] % ./a.out
[588] % ./a.out
0
[589] % ./a.out
0
[590] % cat small.c
int printf(const char *, ...);
int a, c, d;
long b;
char e;
int main() {
d = 4 ^ a;
e = (~(b & 5) & (0 || d) << c) % 4;
if (e > 0)
printf("%d\n", a);
return 0;
}
[Bug rtl-optimization/115928] New: ICE on valid code at -O2 with "-fgcse-sm" on x86_64-linux-gnu: in merge_clobber_groups, at rtl-ssa/accesses.cc:757
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115928
Bug ID: 115928
Summary: ICE on valid code at -O2 with "-fgcse-sm" on
x86_64-linux-gnu: in merge_clobber_groups, at
rtl-ssa/accesses.cc:757
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression as it doesn't reproduce with 14.1 and
earlier.
Compiler Explorer: https://godbolt.org/z/87jKGxq6E
[520] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240714 (experimental) (GCC)
[521] %
[521] % gcctk -O2 -fgcse-sm small.c
during RTL pass: late_combine
small.c: In function ‘main’:
small.c:21:1: internal compiler error: in merge_clobber_groups, at
rtl-ssa/accesses.cc:757
21 | }
| ^
0x24979f5 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:491
0xa462c6 fancy_abort(char const*, int, char const*)
../../gcc-trunk/gcc/diagnostic.cc:1725
0xa3015f rtl_ssa::function_info::merge_clobber_groups(rtl_ssa::clobber_info*,
rtl_ssa::clobber_info*, rtl_ssa::def_info*)
../../gcc-trunk/gcc/rtl-ssa/accesses.cc:757
0x238ea90 rtl_ssa::function_info::remove_def(rtl_ssa::def_info*)
../../gcc-trunk/gcc/rtl-ssa/accesses.cc:1040
0x2394cb1
rtl_ssa::function_info::change_insns(array_slice)
../../gcc-trunk/gcc/rtl-ssa/changes.cc:852
0x233966a run
../../gcc-trunk/gcc/late-combine.cc:452
0x233966a combine_into_uses
../../gcc-trunk/gcc/late-combine.cc:683
0x2339db7 execute
../../gcc-trunk/gcc/late-combine.cc:711
0x2339db7 execute
../../gcc-trunk/gcc/late-combine.cc:760
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.
[522] %
[522] % cat small.c
int a[1], b, c;
struct {
int d;
int e;
int : 8;
} f[1];
static int g;
char h, i, j;
void k(int l) { b = 5 ^ a[b ^ (l & 5)]; }
void m(long l) { k(c >> 6); }
int main() {
g++;
if (b) {
h = 5 && j;
if (h)
h -= i;
m(f[g].d);
m(f[g].e);
}
return 0;
}
[Bug ipa/115926] [12/13/14/15 regression] wrong code at -O1 with "-fno-tree-fre" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115926 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |ipa --- Comment #1 from Andrew Pinski --- This is a dup.
[Bug rtl-optimization/115929] New: ICE on valid code at -O{2, 3} with "-fschedule-insns" on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115929
Bug ID: 115929
Summary: ICE on valid code at -O{2,3} with "-fschedule-insns"
on x86_64-linux-gnu: Segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression as it doesn't reproduce with 14.1 and
earlier.
Compiler Explorer: https://godbolt.org/z/eaE7z3ser
[536] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240714 (experimental) (GCC)
[537] %
[537] % gcctk -O2 -fschedule-insns small.c
during RTL pass: late_combine
small.c: In function ‘main’:
small.c:20:1: internal compiler error: Segmentation fault
20 | }
| ^
0x24979f5 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:491
0x1190963 crash_signal
../../gcc-trunk/gcc/toplev.cc:319
0x7f26ce20a08f ???
/build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x2337afe rtl_ssa::insn_info::is_bb_head() const
../../gcc-trunk/gcc/rtl-ssa/member-fns.inl:610
0x2337afe rtl_ssa::can_insert_after(rtl_ssa::insn_info*)
../../gcc-trunk/gcc/rtl-ssa/movement.h:68
0x2337afe rtl_ssa::canonicalize_move_range(rtl_ssa::insn_range_info&,
rtl_ssa::insn_info*)
../../gcc-trunk/gcc/rtl-ssa/movement.h:78
0x2337afe restrict_movement_for_dead_range<(anonymous
namespace)::insn_combination::substitute_nondebug_use(rtl_ssa::use_info*)::local_ignore>
../../gcc-trunk/gcc/rtl-ssa/movement.h:163
0x2337afe add_regno_clobber<(anonymous
namespace)::insn_combination::substitute_nondebug_use(rtl_ssa::use_info*)::local_ignore>
../../gcc-trunk/gcc/rtl-ssa/member-fns.inl:982
0x2337afe operator()
../../gcc-trunk/gcc/rtl-ssa/change-utils.h:105
0x2337afe _M_invoke
/usr/include/c++/9/bits/std_function.h:285
0x2390667 std::function::operator()(rtl_ssa::insn_change&, unsigned int) const
/usr/include/c++/9/bits/std_function.h:688
0x2390667 add_clobber
../../gcc-trunk/gcc/rtl-ssa/changes.cc:934
0x2390667 recog_level2
../../gcc-trunk/gcc/rtl-ssa/changes.cc:1027
0x2391be8 rtl_ssa::recog_internal(rtl_ssa::insn_change&, std::function)
../../gcc-trunk/gcc/rtl-ssa/changes.cc:1131
0x23389e9 recog<(anonymous
namespace)::insn_combination::substitute_nondebug_use(rtl_ssa::use_info*)::local_ignore>
../../gcc-trunk/gcc/rtl-ssa/change-utils.h:107
0x23389e9 substitute_nondebug_use
../../gcc-trunk/gcc/late-combine.cc:256
0x23389e9 substitute_nondebug_uses
../../gcc-trunk/gcc/late-combine.cc:270
0x23395c5 run
../../gcc-trunk/gcc/late-combine.cc:439
0x23395c5 combine_into_uses
../../gcc-trunk/gcc/late-combine.cc:683
0x2339db7 execute
../../gcc-trunk/gcc/late-combine.cc:711
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.
[538] %
[538] % cat small.c
int a, b, c, d, e, f;
int main() {
if (e && f)
while (1)
while (a)
a = 0;
if (c) {
if (b)
goto g;
int h = a;
i:
b = ~((b ^ h) | 1 % b);
if (a)
g:
b = 0;
}
if (d)
goto i;
return 0;
}
[Bug ipa/115926] [12/13/14/15 regression] wrong code at -O1 with "-fno-tree-fre" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115926 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 114864 ***
[Bug tree-optimization/114864] [12/13/14/15 regression] wrong code at -O1 with "-fno-tree-dce -fno-tree-fre" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114864 --- Comment #6 from Andrew Pinski --- *** Bug 115926 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/115929] [15 regression] ICE on valid code at -O{2,3} with "-fschedule-insns" on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115929
--- Comment #1 from Zhendong Su ---
Another likely related test.
Compiler Explorer: https://godbolt.org/z/o7Wrd7P66
[551] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240714 (experimental) (GCC)
[552] %
[552] % gcctk -O2 -fno-gcse -fschedule-insns -fno-guess-branch-probability
-fno-tree-fre -fno-tree-ch small.c
during RTL pass: late_combine
small.c: In function ‘main’:
small.c:42:1: internal compiler error: in compare_nodes, at
splay-tree-utils.tcc:958
42 | }
| ^
0x24979f5 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:491
0xa462c6 fancy_abort(char const*, int, char const*)
../../gcc-trunk/gcc/diagnostic.cc:1725
0xa30b0f
rootless_splay_tree
>::compare_nodes(rtl_ssa::insn_info::order_node*,
rtl_ssa::insn_info::order_node*)
../../gcc-trunk/gcc/splay-tree-utils.tcc:958
0xa30b0f
rootless_splay_tree
>::compare_nodes(rtl_ssa::insn_info::order_node*,
rtl_ssa::insn_info::order_node*)
../../gcc-trunk/gcc/splay-tree-utils.tcc:944
0xa30b0f rtl_ssa::insn_info::slow_compare_with(rtl_ssa::insn_info const&) const
../../gcc-trunk/gcc/rtl-ssa/insns.cc:88
0x2389403 rtl_ssa::insn_info::compare_with(rtl_ssa::insn_info const*) const
../../gcc-trunk/gcc/rtl-ssa/member-fns.inl:550
0x2389403 operator()
../../gcc-trunk/gcc/rtl-ssa/accesses.cc:549
0x2389403 lookup >
../../gcc-trunk/gcc/splay-tree-utils.tcc:536
0x238ab8a
rtl_ssa::lookup_clobber(rooted_splay_tree
> >&, rtl_ssa::insn_info*)
../../gcc-trunk/gcc/rtl-ssa/accesses.cc:551
0x238ab8a rtl_ssa::function_info::add_clobber(rtl_ssa::clobber_info*,
rtl_ssa::clobber_group*)
../../gcc-trunk/gcc/rtl-ssa/accesses.cc:661
0x238e36c rtl_ssa::function_info::add_def(rtl_ssa::def_info*)
../../gcc-trunk/gcc/rtl-ssa/accesses.cc:950
0x239227a rtl_ssa::function_info::apply_changes_to_insn(rtl_ssa::insn_change&,
hash_set >&)
../../gcc-trunk/gcc/rtl-ssa/changes.cc:688
0x2394de4
rtl_ssa::function_info::change_insns(array_slice)
../../gcc-trunk/gcc/rtl-ssa/changes.cc:888
0x233966a run
../../gcc-trunk/gcc/late-combine.cc:452
0x233966a combine_into_uses
../../gcc-trunk/gcc/late-combine.cc:683
0x2339db7 execute
../../gcc-trunk/gcc/late-combine.cc:711
0x2339db7 execute
../../gcc-trunk/gcc/late-combine.cc:760
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.
[553] %
[553] % cat small.c
int printf(const char *, ...);
int a[6], b, c;
char d, l;
struct {
char e;
int f;
int : 8;
long g;
long h;
} i[1][9] = {0};
unsigned j;
void n(char p) { b = b >> 8 ^ a[b ^ p]; }
int main() {
int k, o;
while (b) {
k = 0;
for (; k < 9; k++) {
b = b ^ a[l];
n(j);
if (o)
printf(&d);
long m = i[c][k].f;
b = b >> 8 ^ a[l];
n(m >> 32);
n(m);
if (o)
printf("%d", d);
b = b >> 8 ^ l;
n(2);
n(0);
if (o)
printf(&d);
b = b ^ a[l];
n(i[c][k].g >> 2);
n(i[c][k].g);
if (o)
printf(&d);
printf("%d", i[c][k].f);
}
}
return 0;
}
[Bug rtl-optimization/115927] [15 regression] wrong code at -O{2,3} with "-fno-tree-vrp" on x86_64-linux-gnu (nondeterministic behavior)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115927
Andrew Pinski changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-07-14
Version|unknown |15.0
Target Milestone|--- |15.0
--- Comment #1 from Andrew Pinski ---
What is missing between 14 and 15 is:
xor edx, edx
is due to ext_dce does:
Processing insn:
13: r116:SI=zero_extend(r117:QI)
REG_DEAD r117:QI
Trying to simplify pattern:
(zero_extend:SI (reg:QI 117))
rescanning insn with uid = 13.
Successfully transformed to:
(subreg:SI (reg:QI 117) 0)
Which originally comes from:
(insn 12 11 13 2 (set (reg:QI 117)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "/app/example.cpp":8:25 1241 {*setcc_qi}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
(insn 13 12 14 2 (set (reg:SI 116 [ _6 ])
(subreg:SI (reg:QI 117) 0)) "/app/example.cpp":8:25 89
{*movsi_internal}
(expr_list:REG_DEAD (reg:QI 117)
(nil)))
But the set QI here does not set the full register; it only touches the lower
part so the zero_extend is still needed.
[Bug rtl-optimization/115929] [15 regression] ICE on valid code at -O{2,3} with "-fschedule-insns" on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115929 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 Version|unknown |15.0 CC||pinskia at gcc dot gnu.org
[Bug tree-optimization/115925] [14/15 regression] wrong code at -O{2,3} with "-fno-thread-jumps" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115925 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.2 Version|unknown |15.0 Target||x86_64-linux-gnu
[Bug c++/109682] coroutines: ICE in morph_fn_to_coro on wrong return type for get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109682
--- Comment #3 from Arsen Arsenović ---
further reduced reproducer (this one should also be fully valid):
#include
#include
struct test
{
test () {}
test (int) {}
struct promise_type {
test get_return_object () { return {}; }
// vvv
static int get_return_object_on_allocation_failure () { return {}; }
std::suspend_never initial_suspend () noexcept { return {}; }
std::suspend_never final_suspend () noexcept { return {}; }
void return_void () {}
void unhandled_exception () {}
};
};
test
f () { co_return; }
int
main ()
{
f ();
}
[Bug rtl-optimization/115877] [15 Regression] wrong code at -Os (missing zero extension)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877 Sam James changed: What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |--- --- Comment #5 from Sam James --- ... actually, this can't be a dupe, as the UBSAN fixup wasn't committed then?
[Bug rtl-optimization/115877] [15 Regression] wrong code at -Os (missing zero extension)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115927 --- Comment #6 from Andrew Pinski --- But it is very similar to PR 115927 .
[Bug c++/115902] [14/15 Regression] Can't call immediate function within "if consteval" when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115902 --- Comment #3 from David Mazières --- This might be the same as Bug 115583.
[Bug c++/115583] [14/15 Regression] C++23: Call to consteval function in `if consteval` immediate function context rejected at -O1 since r14-4140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115583 Andrew Pinski changed: What|Removed |Added CC||gcc at nospam dot scs.stanford.edu --- Comment #4 from Andrew Pinski --- *** Bug 115902 has been marked as a duplicate of this bug. ***
[Bug c++/115902] [14/15 Regression] Can't call immediate function within "if consteval" when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115902 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Yes it is a dup. *** This bug has been marked as a duplicate of bug 115583 ***
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 115902, which changed state. Bug 115902 Summary: [14/15 Regression] Can't call immediate function within "if consteval" when optimizing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115902 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org Target Milestone|--- |15.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #13 from Sam James --- Fixed for 15.
[Bug c++/115706] Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99227 --- Comment #6 from Nathaniel Shead --- Hi, FWIW this is potentially a duplicate of some number of tickets under PR 99227 or similar; I haven't investigated closely as I've been focussing on bugs that already have reductions, and under the assumption that once I fix those bugs the bugs you mention may no longer exist or change. Unfortunately these generic header-module issues typically require reduction before I can confirm them as new bugs rather than duplicates which I haven't had time to do (I can only work on GCC issues a couple of hours a week). Ideally if you would be able to submit one bug per issue that would be amazing, but otherwise you'll have to bear with me, sorry!
[Bug c++/115930] New: ICE: tree check: expected type_argument_pack or nontype_argument_pack, have integer_type in template_parm_natural_p, at cp/mangle.cc:1828
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115930
Bug ID: 115930
Summary: ICE: tree check: expected type_argument_pack or
nontype_argument_pack, have integer_type in
template_parm_natural_p, at cp/mangle.cc:1828
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
Target: x86_64
***
The compiler produces an internal error during tree_check_failed when compiling
the provided code with the specified options.
The issue can also be reproduced on Compiler Explorer.
***
OS and Platform:
# uname -a
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/root/gdbtest/gcc/gcc-15/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /root/gdbtest/gcc/obj/../gcc/configure
--prefix=/root/gdbtest/gcc/gcc-15 --enable-languages=c,c++,fortran,go
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240509 (experimental) (GCC)
***
Program:
# cat source_code_1.cpp
#include
template
struct MemPtrList {};
struct X {
int a;
};
template
int bar () {
std::cout << "bar" << std::endl;
return 42;
}
template
void foo (MemPtrList) {
// Version 1 (miscompile)
int dummy [] = {bar () ... };
// Version 2 (ICE)
// (bar (), ...);
}
int main () {
foo (MemPtrList<&X::a> {});
}
***
Command Lines:
# g++ source_code_1.cpp -O2 -Wall -Wextra -pedantic -std=c++20
-fno-exceptions -fno-rtti -fstrict-aliasing -Wshadow -Wnon-virtual-dtor
-Wold-style-cast -Wcast-align -Woverloaded-virtual -Wconversion
-Wsign-conversion -Wduplicated-cond -Wduplicated-branches -Wlogical-op
-Wnull-dereference -Wuseless-cast -Wdouble-promotion -Wformat=2
-fconcepts-diagnostics-depth=2 -o source_code_1.o
source_code_1.cpp: In function ‘int bar()’:
source_code_1.cpp:11:14: error: ‘cout’ is not a member of ‘std’
11 | std::cout << "bar" << std::endl;
| ^~~~
source_code_1.cpp:1:1: note: ‘std::cout’ is defined in header ‘’;
this is probably fixable by adding ‘#include ’
+++ |+#include
1 |
source_code_1.cpp:11:36: error: ‘endl’ is not a member of ‘std’
11 | std::cout << "bar" << std::endl;
|^~~~
source_code_1.cpp:1:1: note: ‘std::endl’ is defined in header ‘’; this
is probably fixable by adding ‘#include ’
+++ |+#include
1 |
source_code_1.cpp: In instantiation of ‘void foo(MemPtrList) [with
SubPtrTypes = int; SubPtrTypes X::* ...SubRefs = {&X::a}]’:
source_code_1.cpp:25:6: required from here
25 | foo (MemPtrList<&X::a> {});
| ^~
source_code_1.cpp:18:13: warning: unused variable ‘dummy’ [-Wunused-variable]
18 | int dummy [] = {bar () ... };
| ^
source_code_1.cpp: In instantiation of ‘void foo(MemPtrList) [with
SubPtrTypes = int; SubPtrTypes X::* ...SubRefs = {&X::a}]’:
source_code_1.cpp:16:6: internal compiler error: tree check: expected
type_argument_pack or nontype_argument_pack, have integer_type in
template_parm_natural_p, at cp/mangle.cc:1828
16 | void foo (MemPtrList) {
| ^~~
0x99e2c3 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/root/gdbtest/gcc/obj/../gcc/gcc/tree.cc:8995
0x7f561c tree_check2(tree_node*, char const*, int, char const*, tree_code,
tree_code)
/root/gdbtest/gcc/obj/../gcc/gcc/tree.h:3643
0x7f561c template_parm_natural_p
/root/gdbtest/gcc/obj/../gcc/gcc/cp/mangle.cc:1828
0x7f561c write_template_args
/root/gdbtest/gcc/obj/../gcc/gcc/cp/mangle.cc:3224
0xbc5276 write_encoding
/root/gdbtest/gcc/obj/../gcc/gcc/cp/mangle.cc:938
0xbc541b write_mangled_name
/root/gdbtest/gcc/obj/../gcc/gcc/cp/mangle.cc:820
0xbcb4e0 mangle_decl_string
/root/gdbtest/gcc/obj/../gcc/gcc/cp/mangle.cc:4420
0xbcb6ca get_mangled_id
/root/gdbtest/gcc/obj/../gcc/gcc/cp/mangle.cc:4441
0xbcb6ca mangle_decl(tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/mangle.cc:4479
0x16bc0fd decl_assembler_name(tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/tree.cc:719
0xeaaac1 symtab_node::get_comdat_group_id()
/root/gdbtest/gcc
[Bug c++/115706] Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 --- Comment #7 from Dev Dude --- Created attachment 58661 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58661&action=edit A script to try to build gcc module headers A script to try to build gcc module headers, used in absence of knowing any other way to do this, such as via cmake. But running this seems to illicit a stack dump of gcc, which is a bug I would think in the compiler in any case, even if the script is wrong or something.
[Bug rtl-optimization/115049] [14/15 Regression] Silent severe miscompilation around inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049 --- Comment #12 from LIU Hao --- Created attachment 58662 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58662&action=edit test patch
[Bug target/115889] [15 Regression] FAIL: gcc.dg/vect/vect-vfa-03.c execution test with -march=znver4 --param vect-partial-vector-usage=1 since r15-1368-g6d0b7b69d14302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115889 --- Comment #8 from GCC Commits --- The master branch has been updated by Hongyu Wang : https://gcc.gnu.org/g:02a3bf5e2f0c18078bf67fc0002219edba1d76ff commit r15-2030-g02a3bf5e2f0c18078bf67fc0002219edba1d76ff Author: Hongyu Wang Date: Sat Jul 13 11:45:31 2024 +0800 AVX512BF16: Do not allow permutation with vcvtne2ps2bf16 [PR115889] According to the instruction spec of AVX512BF16, the convert from float to BF16 is not a simple truncation. It has special handling for denormal/nan, even for normal float it will add an extra bias according to the least significant bit for bf number. This means we cannot use the vcvtne2ps2bf16 for any bf16 vector shuffle. The optimization introduced in r15-1368 adds a specific split to convert HImode permutation with this instruction, so remove it and treat the BFmode permutation same as HFmode. gcc/ChangeLog: PR target/115889 * config/i386/predicates.md (vcvtne2ps2bf_parallel): Remove. * config/i386/sse.md (hi_cvt_bf): Remove. (HI_CVT_BF): Likewise. (vpermt2_sepcial_bf16_shuffle_):Likewise. gcc/testsuite/ChangeLog: PR target/115889 * gcc.target/i386/vpermt2-special-bf16-shufflue.c: Adjust output scan.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 115889, which changed state. Bug 115889 Summary: [15 Regression] FAIL: gcc.dg/vect/vect-vfa-03.c execution test with -march=znver4 --param vect-partial-vector-usage=1 since r15-1368-g6d0b7b69d14302 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115889 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/115889] [15 Regression] FAIL: gcc.dg/vect/vect-vfa-03.c execution test with -march=znver4 --param vect-partial-vector-usage=1 since r15-1368-g6d0b7b69d14302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115889 Hongtao Liu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||liuhongt at gcc dot gnu.org --- Comment #9 from Hongtao Liu --- Fixed in GCC15.
[Bug c++/115706] Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 --- Comment #8 from Dev Dude --- Hmmm it seems adding an attachment lost my comment. I'll try to remember most of it. First, thanks Nathaniel for your polite comments. Much appreciated. I'm not sure why Sam is mentioning multiple bugs because that was already addressed in creating 115705, which existed prior to his comment about multiple bugs, and he's replied to it in further do nothing fashion. So Bug 115705 is self evident and in it's own report already. Regarding this bug, which is the stack trace, if Sam spent as much time running the small script as complaining that it was pasted rather than attached, he could have confirmed the bug instead of doing nothing here too. And the time Sam spent on 115705 telling me he's doing nothing on it and it's easy, he could have fixed it. I don't need either bug fixed as I only use gcc as a test compiler, I am simply trying to help GCC for that same reason. But I'm not paid for this either, and it takes time to discover gcc's and libstdc++'s problems and write them up in any form, code, let alone write scripts to assist people to see the problems, which I did that Sam ignored only to complain about it. I don't appreciate attitude for simply having the audacity to try to help. It isn't going to be perfect reports every time. If life was perfect, I wouldn't be assisting to fix someone else's screw up anyway. More to the point, I'm not going to fix it, however easy it is, because I don't appreciate this attitude and lest I get further complaints for trying to help. Sam and a few others might want to consider that next time, but these types don't it seems. Somebody should really have a team get together and knock this attitude on the head. Sure I try to get clarity on bug reports myself, but I don't spew out attitude to would be helpers. I wish to clearly note that I am not referring to you Nathaniel, you're extremely polite and helpful, but if somebody reading this can sort this attitude out, it'd be great, because I'm doing nothing more with any of this because of this. So to summarize, there IS only one bug in this report from my perspective, the stack dump to which the attached script relates. Running it, should yield an assert failure of sorts, so running the script should yield a line number in your own builds - it does from trunk, and that should allow for a debug break point to be used to see the state of the compiler, which means a lot more to you lot than me, but this script does reveal some bugs I think, because it's a dump. If it doesn't for you, let me know the circumstance. To be clear, it's failing on on gcc's own headers not my own code. Regardin the line here: [build]88 | mypath = pathbuf; that is from my project, but I don't consider that a bug report, it's just output from using the headers built by the attached script, but as that crashed on headers execution and random on first attempt (with not parameters), it can't be trusted, even though it compiles on second attempt with random and execution as parameters to the script. So it's just some output that that'll likely go away when this bug is fixed and or 115705 is fixed, I just included the line as it might have revealed something for this or 115705. I hope this is helpful Nathaniel and thanks for your supportive commentary. If you wish to do nothing until your other 92277 bug is solved, that's of course fine by me. I will try to build my code again if I see that bug fixed or if you tell me to. Just FYI, I'm unlikely to publicly get involved any more, or certainly with this site and that's fault of yours Nathaniel.
[Bug ipa/110057] Missed devirtualization opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #16 from user202729 ---
(In reply to Jonathan Wakely from comment #14)
> So something like this, and then use it in containers instead of
> _Alloc_traits::destroy
>
> template
> _GLIBCXX20_CONSTEXPR
> void
> _Destroy_static_type(_Tp* __p, _Allocator& __alloc)
> {
> #if __cplusplus >= 201103L
> if constexpr (__allocator_traits_base::__has_destroy<_Allocator, _Tp>)
> allocator_traits<_Allocator>::destroy(__alloc, __p);
> else
> #endif
> __p->_Tp::~_Tp();
> }
That sound like a good idea, thanks. I thought about this some time earlier
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115413#c3) but I did not know how
to check the implementation of `destroy()`.
Nevertheless, this does not handle the case of devirtualization in vector
access (e.g. `v[0].f()` where v is a vector and method f is virtual). What do
you think?
Apart from that, being do you think it is common for the user to override
`destroy()` (in a template specialization) but still call the destructor inside
it? In that case the proposal would not optimize that case.
[Bug target/115526] [14/15 regression] invalid assember emitted for alpha, "Error: duplicate !tlsgd!62" since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526 --- Comment #14 from Sam James --- (In reply to Uroš Bizjak from comment #12) > (In reply to Andreas K. Huettel from comment #11) > > > Can someone please regression test the attached patch? > > > > More in a bit, but: > Any progress with testing? There was some trouble getting some of the test deps on the machine but I believe it's sorted now, just waiting for results to be ready.
[Bug target/115931] New: mips: vec_pack_usat_m's pattern is wrong at gcc/config/mips/loongson-mmi.md:167
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115931 Bug ID: 115931 Summary: mips: vec_pack_usat_m's pattern is wrong at gcc/config/mips/loongson-mmi.md:167 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: lin1.hu at intel dot com Target Milestone: --- If I understand correctly. mips's packuswh(vec_pack_usat_) means convert signed integer to unsigned integer with unsigned saturation. But gcc's us_saturate means unsigned integer convert unsigned integer with unsigned saturation. So the pattern should use UNSPEC.
[Bug rtl-optimization/115932] New: [15 Regression] performance regression after r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115932 Bug ID: 115932 Summary: [15 Regression] performance regression after r15-1619-g3b9b8d6cfdf593 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: jskumari at gcc dot gnu.org Target Milestone: --- Target: cris-elf With r15-1619-g3b9b8d6cfdf593 there was a change in test-suite results for cris-elf that prompted me to run the coremark benchmark test before/after this commit with my usual "-O2 -march=v10" options. See commit r15-1619-g3b9b8d6cfdf593 where I goofed and incorrectly write that there were no changes in results for coremark. However, there *is* a performance regression, from 5179918 to 5181696 cycles i.e. 0.034%. This PR is intended to keep track of similar results for other targets and perhaps a tweak amending r15-1619-g3b9b8d6cfdf593.
[Bug testsuite/115892] [15 regression] gcc.target/aarch64/sve/acle/general/cpy_1.c test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115892 --- Comment #1 from GCC Commits --- The master branch has been updated by Surya Kumari Jangala : https://gcc.gnu.org/g:8b1492012e5a11e9400e30ee4ae9195c08a2a81e commit r15-2034-g8b1492012e5a11e9400e30ee4ae9195c08a2a81e Author: Surya Kumari Jangala Date: Thu Jul 11 11:02:17 2024 -0500 aarch64: Fix the expected output of the test cpy_1.c [PR115892] The fix at r15-1619-g3b9b8d6cfdf593 results in a rearrangement of instructions generated for cpy_1.c. This patch fixes the expected output. 2024-07-12 Surya Kumari Jangala gcc/testsuite: PR testsuite/115892 * gcc.target/aarch64/sve/acle/general/cpy_1.c: Update expected output.
[Bug tree-optimization/115872] [12/13/14/15 regression] ICE in fab pass (error: missing definition with -g & -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115872 --- Comment #3 from GCC Commits --- The releases/gcc-12 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:e1427b39d28f382d21e7a0ea1714b3250e0a6e5d commit r12-10617-ge1427b39d28f382d21e7a0ea1714b3250e0a6e5d Author: liuhongt Date: Fri Jul 12 09:39:23 2024 +0800 Fix SSA_NAME leak due to def_stmt is removed before use_stmt. - _5 = __atomic_fetch_or_8 (&set_work_pending_p, 1, 0); - # DEBUG old => (long int) _5 + _6 = .ATOMIC_BIT_TEST_AND_SET (&set_work_pending_p, 0, 1, 0, __atomic_fetch_or_8); + # DEBUG old => NULL # DEBUG BEGIN_STMT - # DEBUG D#2 => _5 & 1 + # DEBUG D#2 => NULL ... - _10 = ~_5; - _8 = (_Bool) _10; - # DEBUG ret => _8 + _8 = _6 == 0; + # DEBUG ret => (_Bool) _10 confirmed. convert_atomic_bit_not does this, it checks for single_use and removes the def, failing to release the name (which would fix this up IIRC). Note the function removes stmts in "wrong" order (before uses of LHS are removed), so it requires larger surgery. And it leaks SSA names. gcc/ChangeLog: PR target/115872 * tree-ssa-ccp.cc (convert_atomic_bit_not): Remove use_stmt after use_nop_stmt is removed. (optimize_atomic_bit_test_and): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr115872.c: New test. (cherry picked from commit a8209237dc46dc4db7d9d8e3807e6c93734c64b5)
[Bug tree-optimization/115872] [12/13/14/15 regression] ICE in fab pass (error: missing definition with -g & -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115872 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:9a1cdaa5e8441394d613f5f3401e7aab21efe8f0 commit r13-8913-g9a1cdaa5e8441394d613f5f3401e7aab21efe8f0 Author: liuhongt Date: Fri Jul 12 09:39:23 2024 +0800 Fix SSA_NAME leak due to def_stmt is removed before use_stmt. - _5 = __atomic_fetch_or_8 (&set_work_pending_p, 1, 0); - # DEBUG old => (long int) _5 + _6 = .ATOMIC_BIT_TEST_AND_SET (&set_work_pending_p, 0, 1, 0, __atomic_fetch_or_8); + # DEBUG old => NULL # DEBUG BEGIN_STMT - # DEBUG D#2 => _5 & 1 + # DEBUG D#2 => NULL ... - _10 = ~_5; - _8 = (_Bool) _10; - # DEBUG ret => _8 + _8 = _6 == 0; + # DEBUG ret => (_Bool) _10 confirmed. convert_atomic_bit_not does this, it checks for single_use and removes the def, failing to release the name (which would fix this up IIRC). Note the function removes stmts in "wrong" order (before uses of LHS are removed), so it requires larger surgery. And it leaks SSA names. gcc/ChangeLog: PR target/115872 * tree-ssa-ccp.cc (convert_atomic_bit_not): Remove use_stmt after use_nop_stmt is removed. (optimize_atomic_bit_test_and): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr115872.c: New test. (cherry picked from commit a8209237dc46dc4db7d9d8e3807e6c93734c64b5)
[no subject]
สำหรับเจ้าของกิจการ ที่มี Project ต่อยอดเพิ่มกำไรให้ธุรกิจ แต่ยังหาทุนทรัพย์ไม่ทัน (เราช่วยคุณได้) ✔️สำหรับเจ้าของธุรกิจที่มีการจดทะเบียน ใบประกอบกิจการ ✔️อนุมัติสูงสุด 5,000,000 บาท ✔️ไม่เช็คเครดิต บูโรเอกสารไม่ยุ่งยาก ไม่ต้องมีบุคคลค้ำประกัน ✔️อัตราดอกเบี้ยเริ่มต้น1.5% ✔️ตัดต้นลดดอกเบี้ยทันที ถ้าท่านสนใจบริการของเรา โทรด่วนหาเรา ☎️ 0936782499 คุณตะวัน ☎️ 0825928519 คุณเอก Line ID : esc.credit (ให้เราเป็นส่วนหนึ่งในครอบครับท่านนะครับ)
[Bug tree-optimization/115872] [12/13/14/15 regression] ICE in fab pass (error: missing definition with -g & -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115872 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:13bfc385b0baebd22aeabb0d90915f2e9b18febe commit r14-10422-g13bfc385b0baebd22aeabb0d90915f2e9b18febe Author: liuhongt Date: Fri Jul 12 09:39:23 2024 +0800 Fix SSA_NAME leak due to def_stmt is removed before use_stmt. - _5 = __atomic_fetch_or_8 (&set_work_pending_p, 1, 0); - # DEBUG old => (long int) _5 + _6 = .ATOMIC_BIT_TEST_AND_SET (&set_work_pending_p, 0, 1, 0, __atomic_fetch_or_8); + # DEBUG old => NULL # DEBUG BEGIN_STMT - # DEBUG D#2 => _5 & 1 + # DEBUG D#2 => NULL ... - _10 = ~_5; - _8 = (_Bool) _10; - # DEBUG ret => _8 + _8 = _6 == 0; + # DEBUG ret => (_Bool) _10 confirmed. convert_atomic_bit_not does this, it checks for single_use and removes the def, failing to release the name (which would fix this up IIRC). Note the function removes stmts in "wrong" order (before uses of LHS are removed), so it requires larger surgery. And it leaks SSA names. gcc/ChangeLog: PR target/115872 * tree-ssa-ccp.cc (convert_atomic_bit_not): Remove use_stmt after use_nop_stmt is removed. (optimize_atomic_bit_test_and): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr115872.c: New test. (cherry picked from commit a8209237dc46dc4db7d9d8e3807e6c93734c64b5)
[Bug tree-optimization/115872] [12/13/14/15 regression] ICE in fab pass (error: missing definition with -g & -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115872 Hongtao Liu changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Hongtao Liu --- Fixed in GCC12.5, GCC13.4, GCC14.2 and main trunk.
[Bug testsuite/115894] [15 regression] gcc.target/arm/pr111235.c test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115894 --- Comment #1 from GCC Commits --- The master branch has been updated by Surya Kumari Jangala : https://gcc.gnu.org/g:60ba989220d9dec07d82009b0dafe684e652577f commit r15-2036-g60ba989220d9dec07d82009b0dafe684e652577f Author: Surya Kumari Jangala Date: Mon Jul 15 00:03:06 2024 -0500 arm: Fix the expected output of the test pr111235.c [PR115894] With r15-1619-g3b9b8d6cfdf593, pr111235.c fails due to different registers used in ldrexd instruction. The key part of this test is that the compiler generates LDREXD. The registers used for that are pretty much irrelevant as they are not matched with any other operations within the test. This patch changes the test to test only for the mnemonic and not for any of the operands. 2024-07-15 Surya Kumari Jangala gcc/testsuite: PR testsuite/115894 * gcc.target/arm/pr111235.c: Update expected output.
[Bug testsuite/115892] [15 regression] gcc.target/aarch64/sve/acle/general/cpy_1.c test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115892 Surya Kumari Jangala changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Surya Kumari Jangala --- Fixed in r15-2034-g8b1492012e5a11
