[Bug c++/114439] [14 Regression] icu4c-73.2 build failure: invalid initializer for array member with initialization of array of struct containing arrays since r14-9622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114439 --- Comment #6 from Sergei Trofimovich --- The change also fixed full icu4c-73.2 build for me. Thank you!
[Bug c++/114439] [14 Regression] icu4c-73.2 build failure: invalid initializer for array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114439 Sergei Trofimovich changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Sergei Trofimovich --- Bisected down to r14-9622-gd1d8fd2884b445 "c++: direct-init of an array of class type [PR59465]".
[Bug c++/114439] New: [14 Regression] icu4c-73.2 build failure: invalid initializer for array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114439
Bug ID: 114439
Summary: [14 Regression] icu4c-73.2 build failure: invalid
initializer for array member
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially observed build failure on icu4c-73.2 using gcc
r14-9636-gc2e28df90a1640 .
The build fails there as:
regexst.cpp: In constructor
'icu_73::RegexStaticSets::RegexStaticSets(UErrorCode*)':
regexst.cpp:75:52: error: invalid initializer for array member
'icu_73::UnicodeSet icu_73::RegexStaticSets::fPropSets [13]'
75 | RegexStaticSets::RegexStaticSets(UErrorCode *status) {
|^
regexst.cpp:75:52: error: invalid initializer for array member
'icu_73::Regex8BitSet icu_73::RegexStaticSets::fPropSets8 [13]'
regexst.cpp:75:52: error: invalid initializer for array member
'icu_73::UnicodeSet icu_73::RegexStaticSets::fRuleSets [3]'
Minimized example:
$ cat regexst.cpp.cpp
struct UnicodeSet {
int *list = stackList;
int stackList[];
};
struct RegexStaticSets {
RegexStaticSets() {}
UnicodeSet fPropSets[2]{};
};
$ g++-14 -std=c++11 -c regexst.cpp.cpp -o bug.o
regexst.cpp.cpp: In constructor 'RegexStaticSets::RegexStaticSets()':
regexst.cpp.cpp:6:21: error: invalid initializer for array member 'UnicodeSet
RegexStaticSets::fPropSets [2]'
6 | RegexStaticSets() {}
| ^
For comparison gcc-13 looks fine:
$ g++-13 -std=c++11 -c regexst.cpp.cpp -o bug.o
Compiler version:
$ g++-14 -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.1/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.1/libexec/gcc/x86_64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-14.0.1
--with-gmp-include=/<>/gmp-6.3.0-dev/include
--with-gmp-lib=/<>/gmp-6.3.0/lib
--with-mpfr-include=/<>/mpfr-4.2.1-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.1/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.39-dev/include
--with-build-sysroot=/
--with-gxx-include-dir=/<>/gcc-14.0.1/include/c++/14.0.1/
--program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --disable-bootstrap
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 (experimental) (GCC)
[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527 --- Comment #5 from Sergei Trofimovich --- (In reply to Deepthi H from comment #4) > I have been investigating this issue further. Hence checking the source code > and debugging the gcc sources. However, I wasn't able to find where the > COLLECT_GCC_OPTION has been set to 128kb > > I couldn't find it being set in gcc. Can you please let us know how can we > increase the limit of collect options? The 128K limit against a single environment variable is a linux kernel limitation set by this define in include/uapi/linux/binfmts.h: #define MAX_ARG_STRLEN (PAGE_SIZE * 32) https://trofi.github.io/posts/299-maximum-argument-count-on-linux-and-in-gcc.html has more words on that.
[Bug c++/113141] [13/14 Regression] ICE on conversion to reference in aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113141
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comment #4 from Sergei Trofimovich ---
Noticed a similar ICE in openmvs-2.2.0 against gcc-13/gcc-14. I reduced it with
cvise into something invalid:
$ cat SceneDensify.cpp.cpp
class Matrix struct TPoint3 {
typedef Matrix EVec;
operator const EVec();
void Init() {
TPoint3 X;
(EVec &)X;
}
};
$ g++ -c SceneDensify.cpp.cpp -o bug.o
SceneDensify.cpp.cpp: In member function 'void TPoint3::Init()':
SceneDensify.cpp.cpp:6:13: internal compiler error: in reference_binding, at
cp/call.cc:2020
6 | (EVec &)X;
| ^
[Bug bootstrap/113445] [14 Regression] bootstrap failure on f95-lang.cc: ‘-fcompare-debug’ failure since r14-8174
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113445 --- Comment #10 from Sergei Trofimovich --- The patch fixes bootstrap for me as well. Thank you!
[Bug bootstrap/113445] New: [14 Regression] bootstrap failure on f95-lang.cc: ‘-fcompare-debug’ failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113445
Bug ID: 113445
Summary: [14 Regression] bootstrap failure on f95-lang.cc:
‘-fcompare-debug’ failure
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed bootstrap failure on today's gcc-master from r14-8179-g97089a54f7529a:
$ ~/dev/git/gcc/configure --disable-multilib CFLAGS='-O1 -g0' CXXFLAGS='-O1
-g0' LDFLAGS='-O1 -g0'
Comparing stages 2 and 3
Bootstrap comparison failure!
Minimized example:
// $ cat f95-lang.cc.cc
int global_options_3, gfc_init_builtin_functions_builtin_types_0,
gfc_init_builtin_functions_builtin_types_26,
gfc_init_builtin_functions_builtin_types_3,
gfc_init_builtin_functions_builtin_types_17,
gfc_init_builtin_functions_builtin_types_12,
gfc_init_builtin_functions_builtin_types_2;
int *global_trees_7, *global_trees_0, *integer_types_1, *integer_types_0;
int *build_pointer_type(int *);
int *build_function_type_list(...);
int *gfc_type_for_size(unsigned, int);
void gfc_define_builtin(int *, int);
void gfc_init_builtin_functions() {
int *__trans_tmp_4, *__trans_tmp_3, *__trans_tmp_2, *builtin_types_45,
*builtin_types_39, *builtin_types_34, *builtin_types_19,
*builtin_types_11, *builtin_types_6, *builtin_types_5, *builtin_types_4 =
integer_types_0;
int builtin_types_16, builtin_types_15, builtin_types_1;
builtin_types_5 = integer_types_1;
builtin_types_6 = global_trees_7;
int *type = gfc_type_for_size(0, 1);
__trans_tmp_2 = __trans_tmp_3 = type ?: global_trees_0;
__trans_tmp_4 = global_trees_0;
builtin_types_11 = build_function_type_list();
builtin_types_19 =
build_pointer_type(_init_builtin_functions_builtin_types_17);
build_function_type_list(builtin_types_15);
build_function_type_list(builtin_types_16);
build_function_type_list();
build_function_type_list(gfc_init_builtin_functions_builtin_types_12,
__trans_tmp_4, __null);
build_function_type_list();
build_function_type_list();
build_function_type_list();
build_function_type_list(__trans_tmp_3);
build_function_type_list(__trans_tmp_4);
build_function_type_list();
build_pointer_type(_init_builtin_functions_builtin_types_26);
build_function_type_list();
build_function_type_list(builtin_types_1,
gfc_init_builtin_functions_builtin_types_12,
__trans_tmp_3, __null);
builtin_types_34 = build_function_type_list(
gfc_init_builtin_functions_builtin_types_12, __trans_tmp_4, __null);
build_function_type_list(gfc_init_builtin_functions_builtin_types_12,
__trans_tmp_2, __null);
build_function_type_list(__trans_tmp_3, __null);
build_function_type_list(__null);
build_function_type_list(__null);
builtin_types_39 = build_function_type_list();
build_function_type_list(__null);
build_function_type_list(gfc_init_builtin_functions_builtin_types_0,
builtin_types_19, builtin_types_11,
gfc_init_builtin_functions_builtin_types_3,
gfc_init_builtin_functions_builtin_types_3,
gfc_init_builtin_functions_builtin_types_3, __null);
builtin_types_45 = build_function_type_list( builtin_types_1,
builtin_types_4, builtin_types_4, builtin_types_4, builtin_types_15,
builtin_types_15, __null);
build_function_type_list(
gfc_init_builtin_functions_builtin_types_0, builtin_types_6,
gfc_init_builtin_functions_builtin_types_12, builtin_types_11,
builtin_types_11, gfc_init_builtin_functions_builtin_types_2, __null);
build_function_type_list(gfc_init_builtin_functions_builtin_types_0,
gfc_init_builtin_functions_builtin_types_2,
builtin_types_6, builtin_types_11, builtin_types_11,
builtin_types_11, __null);
build_function_type_list(builtin_types_1,
gfc_init_builtin_functions_builtin_types_3,
builtin_types_15, builtin_types_4, builtin_types_15,
builtin_types_15, __null);
build_function_type_list( builtin_types_1,
gfc_init_builtin_functions_builtin_types_3, builtin_types_16,
builtin_types_5, builtin_types_16, builtin_types_4, builtin_types_4,
builtin_types_15, builtin_types_1, builtin_types_1, builtin_types_5,
builtin_types_5, builtin_types_5, builtin_types_16, builtin_types_16);
gfc_define_builtin(builtin_types_34, 0);
gfc_define_builtin(builtin_types_39, 6
[Bug bootstrap/113132] [14 regression] --enable-checking=release build fails: tree-vect-loop.cc:6221:34: error: ‘vec_stmts.vec::m_vec’ may be used uninitialized [-Werror=mayb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113132 Sergei Trofimovich changed: What|Removed |Added CC||tamar.christina at arm dot com --- Comment #1 from Sergei Trofimovich --- Might be exposed by r14-6822-g01f4251b8775c8 "middle-end: Support vectorization of loops with multiple exits."
[Bug bootstrap/113132] New: [14 regression] --enable-checking=release build fails: tree-vect-loop.cc:6221:34: error: ‘vec_stmts.vec::m_vec’ may be used uninitialized [-Werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113132 Bug ID: 113132 Summary: [14 regression] --enable-checking=release build fails: tree-vect-loop.cc:6221:34: error: ‘vec_stmts.vec::m_vec’ may be used uninitialized [-Werror=maybe-uninitialized] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Noticed on today's build of master r14-6828-g0beeddd6b1b1cb : $ ../gcc/configure --disable-multilib --enable-checking=release $ make ... /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -fno-PIE -I. -I. -I/home/slyfox/dev/git/gcc/gcc -I/home/slyfox/dev/git/gcc/gcc/. -I/home/slyfox/dev/git/gcc/gcc/../include -I/home/slyfox/dev/git/gcc/gcc/../libcpp/include -I/home/slyfox/dev/git/gcc/gcc/../libcody -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libbacktrace -o tree-vect-loop.o -MT tree-vect-loop.o -MMD -MP -MF ./.deps/tree-vect-loop.TPo /home/slyfox/dev/git/gcc/gcc/tree-vect-loop.cc /home/slyfox/dev/git/gcc/gcc/tree-vect-loop.cc: In function 'void vect_create_epilog_for_reduction(loop_vec_info, stmt_vec_info, slp_tree, slp_instance, edge)': /home/slyfox/dev/git/gcc/gcc/tree-vect-loop.cc:6221:34: error: 'vec_stmts.vec::m_vec' may be used uninitialized [-Werror=maybe-uninitialized] 6221 | def = gimple_get_lhs (vec_stmts[j]); | ~~~^~ /home/slyfox/dev/git/gcc/gcc/tree-vect-loop.cc:6210:18: note: 'vec_stmts.vec::m_vec' was declared here 6210 | vec vec_stmts; | ^ cc1plus: all warnings being treated as errors make[3]: *** [Makefile:1198: tree-vect-loop.o] Error 1 make[3]: Leaving directory '/tmp/gb/gcc' make[2]: *** [Makefile:5094: all-stage2-gcc] Error 2 make[2]: Leaving directory '/tmp/gb' make[1]: *** [Makefile:26393: stage2-bubble] Error 2 make[1]: Leaving directory '/tmp/gb' make: *** [Makefile:1096: all] Error 2 $ ./gcc/xgcc -v Using built-in specs. COLLECT_GCC=./gcc/xgcc Target: x86_64-pc-linux-gnu Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib --enable-checking=release Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20231225 (experimental) (GCC)
[Bug tree-optimization/112991] [14 Regression] ICE during GIMPLE pass: ifcvt on p7zip-17.05 since r14-6457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112991 --- Comment #5 from Sergei Trofimovich --- The change also fixes p7zip-17.05 build for me. Thank you!
[Bug tree-optimization/112991] New: [14 Regression] ICE during GIMPLE pass: ifcvt on p7zip-17.05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112991
Bug ID: 112991
Summary: [14 Regression] ICE during GIMPLE pass: ifcvt on
p7zip-17.05
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed ICE on current gcc-master when built p7zip-17.05 with
r14-6466-gcd7d0b4cf78926 . Minimized example:
$ cat a.c.c
typedef struct {
unsigned links[2];
} RMF_unit;
long RMF_recurseListsBound_count;
int RMF_recurseListsBound_tbl, RMF_recurseListsBound_list_head_1;
unsigned RMF_recurseListsBound_list_head_0;
void RMF_recurseListsBound() {
int list_count = RMF_recurseListsBound_list_head_1;
long link = RMF_recurseListsBound_list_head_0;
for (; RMF_recurseListsBound_count;) {
long next_link =
((RMF_unit *)_recurseListsBound_tbl)[link >> 2].links[0];
if (link)
--RMF_recurseListsBound_count;
link = next_link;
}
while (list_count)
;
}
$ gcc -std=gnu11 -O2 -c a.c.c -O2 -Wall -Werror
a.c.c: In function 'RMF_recurseListsBound':
a.c.c:12:49: error: array subscript 'RMF_unit[0]' is partly outside array
bounds of 'int[1]' [-Werror=array-bounds=]
12 | ((RMF_unit *)_recurseListsBound_tbl)[link >> 2].links[0];
| ^~~
a.c.c:5:5: note: object 'RMF_recurseListsBound_tbl' of size 4
5 | int RMF_recurseListsBound_tbl, RMF_recurseListsBound_list_head_1;
| ^
during GIMPLE pass: ifcvt
a.c.c:7:6: internal compiler error: Segmentation fault
7 | void RMF_recurseListsBound() {
| ^
0x1e367b4 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x1e36f99 internal_error(char const*, ...)
???:0
0xd621af crash_signal(int)
???:0
0x9d2ad0 tree_single_nonnegative_warnv_p(tree_node*, bool*, int)
???:0
0xa3be95 gimple_stmt_nonnegative_warnv_p(gimple*, bool*, int)
???:0
0x9d2c45 tree_expr_nonnegative_p(tree_node*)
???:0
0x123e667 gimple_simplify_369(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node*, tree_node**, tree_code)
???:0
0x13978ff gimple_simplify_RSHIFT_EXPR(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*)
???:0
0x139e78d gimple_resimplify2(gimple**, gimple_match_op*, tree_node*
(*)(tree_node*))
???:0
0x139f327 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
???:0
0xa30915 gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
???:0
0xf3f55c visit_stmt(gimple*, bool) [clone .isra.0]
???:0
0xf4000d process_bb(rpo_elim&, basic_block_def*, bool, bool, bool, bool, bool,
bitmap_head*, bool)
???:0
0xf417d7 do_rpo_vn_1(function*, edge_def*, bitmap_head*, bool, bool,
vn_lookup_kind)
???:0
0xf42a2a do_rpo_vn(function*, edge_def*, bitmap_head*, bool, bool,
vn_lookup_kind)
???:0
0xdcdbd6 tree_if_conversion(loop*, vec*)
???:0
0xdd030a (anonymous namespace)::pass_if_conversion::execute(function*)
???:0
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.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-14.0.0
--with-gmp-include=/<>/gmp-6.3.0-dev/include
--with-gmp-lib=/<>/gmp-6.3.0/lib
--with-mpfr-include=/<>/mpfr-4.2.1-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.1/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.38-27-dev/include
--with-build-sysroot=/ --program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --disable-bootstrap
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 (experimental) (GCC)
[Bug c++/112869] [14 Regression] ICE at gimplify_expr, at gimplify.cc:17531 on libopenmpt-0.7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112869 --- Comment #3 from Sergei Trofimovich --- I confirm the proposed change fixes build of libopenmpt-0.7.3 as well. Thank you!
[Bug c++/112869] New: [14 regression] ICE at gimplify_expr, at gimplify.cc:17531 on libopenmpt-0.7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112869
Bug ID: 112869
Summary: [14 regression] ICE at gimplify_expr, at
gimplify.cc:17531 on libopenmpt-0.7.3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially observed ICE on gcc-master at r14-6191-g9c3a880feecf81 compiling
libopenmpt-0.7.3.
Extracted example:
$ cat a.cpp.cpp
void min(long, long);
template void Binaryread(int &, T, unsigned long);
template <> void Binaryread(int &, float, unsigned long bytecount) {
min(bytecount, sizeof(int));
}
Crashing:
$ g++ -std=c++20 -c a.cpp.cpp -o a.o
a.cpp.cpp: In function 'void Binaryread(int&, T, long unsigned int) [with T =
float]':
a.cpp.cpp:4:18: internal compiler error: in gimplify_expr, at gimplify.cc:17531
4 | min(bytecount, sizeof(int));
| ^~~
0x1fe24d4 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x1fe2cb9 internal_error(char const*, ...)
???:0
0x76d566 fancy_abort(char const*, int, char const*)
???:0
0x7387b4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int) [clone .cold]
???:0
0xc30cb6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xc35c39 gimplify_arg(tree_node**, gimple**, unsigned int, bool)
???:0
0xc35e9d gimplify_call_expr(tree_node**, gimple**, bool)
???:0
0xc3158e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xc34b33 gimplify_cleanup_point_expr(tree_node**, gimple**)
???:0
0xc315e2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xc3428e gimplify_body(tree_node*, bool)
???:0
0xc34650 gimplify_function_tree(tree_node*)
???:0
0xa9bf07 cgraph_node::analyze()
???:0
0xa9e607 analyze_functions(bool)
???:0
0xa9f27d symbol_table::finalize_compilation_unit()
???:0
$ LANG=C 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 14.0.0 20231205 (experimental) (GCC)
[Bug tree-optimization/112711] [14 Regression] SRA seems to ignore writes when using __builtin_assume_aligned since r14-5831-gaae723d360ca26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112711 --- Comment #9 from Sergei Trofimovich --- The change also fixes llvm-16.0.6 testsuite for me. Thank you!
[Bug tree-optimization/112711] [14 Regression] SRA seems to ignore writes when using __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112711 --- Comment #3 from Sergei Trofimovich --- I confirm bisect landed on r14-5831-gaae723d360ca26 as well.
[Bug middle-end/112711] New: [14 Regression] possibly wrong code in bswap32(int) on llvm-16.0.6 test suite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112711
Bug ID: 112711
Summary: [14 Regression] possibly wrong code in bswap32(int) on
llvm-16.0.6 test suite
Product: gcc
Version: 14.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: ---
Initially noticed possibly wrong code on llvm-16.0.6 test suite when building
with gcc-master from r14-5844-g9c26c91b94eb72:
Failed Tests (2):
LLVM-Unit :: Support/./SupportTests/Endian/Write
LLVM-Unit :: Support/./SupportTests/Endian/WriteBitAligned
I extracted the following self-contained example:
// $ cat EndianTest.cpp
typedef int i32;
typedef unsigned int u32;
static inline void write_i32(void *memory, i32 value) {
// swap i32 bytes as if it was u32:
u32 u_value = value;
value = __builtin_bswap32(u_value);
// llvm infers '1' alignment from destination type
__builtin_memcpy(__builtin_assume_aligned(memory, 1), , sizeof(value));
}
__attribute__((noipa))
static void bug (void) {
#define assert_eq(lhs, rhs) if (lhs != rhs) __builtin_trap()
unsigned char data[5];
write_i32(data, -1362446643);
assert_eq(data[0], 0xAE);
assert_eq(data[1], 0xCA);
write_i32(data + 1, -1362446643);
assert_eq(data[1], 0xAE);
}
int main() {
bug();
}
Fails as:
$ gcc/xg++ -Bgcc EndianTest.cpp -o bug -O0 && ./bug
$ gcc/xg++ -Bgcc EndianTest.cpp -o bug -O2 && ./bug
Illegal instruction (core dumped)
$ 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 14.0.0 20231125 (experimental) (GCC)
[Bug target/112613] gcc generates incorrect argument reads at prologue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112613 --- Comment #3 from Sergei Trofimovich --- > since the bad instruction is a compare, it does seem like it might be solved > via https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572#c18 too. compare > elimination is going wrong. Yeah, that fixes it. Looking at a bad case bug.cpp.317r.cmpelim contains the following start of the function: 1: NOTE_INSN_DELETED 922: NOTE_INSN_BASIC_BLOCK 2 889: [bp:DI-0x130]=di:DI 888: r14:DI=si:DI REG_UNUSED r14:DI 4: r12:DI=zero_extend(dx:SI) REG_DEAD dx:SI 6: bx:DI=r8:DI REG_DEAD r8:DI 7: NOTE_INSN_FUNCTION_BEG 818: si:DI=r14:DI 16: flags:CCZ=cmp([si:DI+0x10],0x5b) The 'REG_UNUSED r14:DI' looks wrong. That possibly caused use of dangling register. I wonder if `gcc` could fail in -fchecking= mode if it's a reasonable check.
[Bug middle-end/112572] [14 regression] LLVM miscompiled since r14-5355-g3cd3a09b3f91a1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572 --- Comment #19 from Sergei Trofimovich --- I spent some time poking at the bug and was not able to reproduce it on my toolchain. I was able to get it to fail on gentoo's toolchain and arrived at problems in lib/Target/X86/X86InterleavedAccess.cpp. My theory is that X86InterleavedAccessGroup::decompose() gets compiled incorrectly. `-fPIE` seems to be the flag that triggers gcc to generate slightly incorrect prologue (wrong register is being used). I filed a separate issue in case it's an invalid manual reduction: https://gcc.gnu.org/PR112613
[Bug target/112613] gcc generates incorrect argument reads at prologue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112613 --- Comment #1 from Sergei Trofimovich --- Created attachment 56635 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56635=edit bug.cpp.xz
[Bug target/112613] New: gcc generates incorrect argument reads at prologue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112613
Bug ID: 112613
Summary: gcc generates incorrect argument reads at prologue
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
This is an example extracted from an attempt to debug PR112572.
Attached file is not directly executable. And it's not easy to amoend to make
it executable, but I think it illustrates the problem well:
For the following function in the source file:
__attribute__((noipa))
void X86InterleavedAccessGroup::decompose(
Instruction *VecInst, unsigned NumSubVectors, FixedVectorType *SubVecTy,
SmallVectorImpl ) {
if (ShuffleVectorInst *SVI = dyn_cast(VecInst)) {
...
gcc generates the following prologue:
$ gcc/xg++ -Bgcc -O2 -march=znver2 -fno-checking -fno-lifetime-dse -std=c++17
-S /tmp/bug.cpp -o - -fPIE
...
_ZN1n25X86InterleavedAccessGroup9decomposeEPN4llvm11InstructionEjPNS1_15FixedVectorTypeERNS1_15SmallVectorImplIS3_EE:
.LFB19440:
.cfi_startproc
.cfi_personality 0x9b,DW.ref.__gxx_personality_v0
.cfi_lsda 0x1b,.LLSDA19440
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
pushq %r15
pushq %r14
pushq %r13
pushq %r12
pushq %rbx
.cfi_offset 15, -24
.cfi_offset 14, -32
.cfi_offset 13, -40
.cfi_offset 12, -48
.cfi_offset 3, -56
movl%edx, %r12d
movq%r8, %rbx
subq$328, %rsp
cmpb$91, 16(%r14) // <- what is %r14? it should be %rsi
...
I think %r14 is an invalid value. It should be something like %rsi (that's what
-fno-PIE does).
I hope this example is analysable to get the idea why this register is chosen.
$ 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 14.0.0 20231118 (experimental) (GCC)
[Bug ipa/112601] New: ICE in cgraph_node::verify_node(): error: invalid calls_comdat_local flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112601
Bug ID: 112601
Summary: ICE in cgraph_node::verify_node(): error: invalid
calls_comdat_local flag
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Encountered the bug when tried to build llvm-17.0.5 with -O1 optimization
flags.
Looks like all the gcc versions I tried fail starting from gcc-10 including
current gcc-master r14-5563-gbc274b8d677212.
Extracted reproducer:
// $ cat a.cpp
bool neq(int, int);
int begin();
int end();
void deref(int);
struct Twine {
Twine(const char *);
};
int (int, Twine);
void out6(int, Twine);
static void printChar(int &, char) {}
int emitStringLiteralDef_OS, emit_OS, emit_I;
char emit___trans_tmp_1;
struct SequenceToOffsetTable {
void emitStringLiteralDef(Twine Decl) {
emit(printChar);
int __trans_tmp_6 = out(emitStringLiteralDef_OS, ""),
__trans_tmp_5 = out(__trans_tmp_6, ""),
__trans_tmp_4 = out(__trans_tmp_5, ""),
__trans_tmp_3 = out(__trans_tmp_4, ""),
__trans_tmp_2 = out(__trans_tmp_3, Decl);
out6(__trans_tmp_2, "");
}
void emit(void Print(int &, char)) {
for (int E = 0; neq(emit_I, E);)
for (int SI = (deref(emit_I), begin)(), SE = (deref(emit_I), end)();
neq(SI, SE);)
Print(emit_OS, emit___trans_tmp_1);
}
};
void run() {
SequenceToOffsetTable RegStrings;
RegStrings.emitStringLiteralDef(0);
}
Crashing:
$ gcc/xg++ -B./gcc -O1 -fchecking=2 -c a.cpp -o a.o
a.cpp: In member function 'void
SequenceToOffsetTable::emitStringLiteralDef(Twine)':
a.cpp:14:8: error: invalid calls_comdat_local flag
14 | void emitStringLiteralDef(Twine Decl) {
|^~~~
_ZN21SequenceToOffsetTable20emitStringLiteralDefE5Twine/5 (void
SequenceToOffsetTable::emitStringLiteralDef(Twine))
Type: function definition analyzed
Visibility: externally_visible semantic_interposition public weak comdat
comdat_group:_ZN21SequenceToOffsetTable20emitStringLiteralDefE5Twine one_only
Same comdat group as: _ZL9printCharRic/0
References:
Referring:
Availability: available
Function flags: count:1073741824 (estimated locally) body
Called by: _Z3runv/7 (1073741824 (estimated locally),1.00 per call) (can
throw external)
Calls: _Z3neqii/15 (9761289262 (estimated locally),9.09 per call) (can throw
external) _Z3neqii/15 (78977704412 (estimated locally),73.55 per call) (can
throw external) _ZL9printCharRic/0 (70290156974 (estimated locally),65.46 per
call) (can throw external) _Z3endv/14 (8687547438 (estimated locally),8.09 per
call) (can throw external) _Z5derefi/12 (8687547438 (estimated locally),8.09
per call) (can throw external) _Z5beginv/13 (8687547438 (estimated
locally),8.09 per call) (can throw external) _Z5derefi/12 (8687547438
(estimated locally),8.09 per call) (can throw external) _Z4out6i5Twine/11
(1073741824 (estimated locally),1.00 per call) (can throw external)
_ZN5TwineC1EPKc/8 (1073741824 (estimated locally),1.00 per call) (can throw
external) _Z3outi5Twine/10 (1073741824 (estimated locally),1.00 per call) (can
throw external) _Z3outi5Twine/10 (1073741824 (estimated locally),1.00 per call)
(can throw external) _ZN5TwineC1EPKc/8 (1073741824 (estimated locally),1.00 per
call) (can throw external) _Z3outi5Twine/10 (1073741824 (estimated
locally),1.00 per call) (can throw external) _ZN5TwineC1EPKc/8 (1073741824
(estimated locally),1.00 per call) (can throw external) _Z3outi5Twine/10
(1073741824 (estimated locally),1.00 per call) (can throw external)
_ZN5TwineC1EPKc/8 (1073741824 (estimated locally),1.00 per call) (can throw
external) _Z3outi5Twine/10 (1073741824 (estimated locally),1.00 per call) (can
throw external) _ZN5TwineC1EPKc/8 (1073741824 (estimated locally),1.00 per
call) (can throw external)
during IPA pass: inline
a.cpp:14:8: internal compiler error: verify_cgraph_node failed
0x258970b diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x258a52e internal_error(char const*, ...)
???:0
0xc767c2 cgraph_node::verify_node()
???:0
0xc64d11 symtab_node::verify()
???:0
0x1276003 optimize_inline_calls(tree_node*)
???:0
0xf10813 inline_transform(cgraph_node*)
???:0
0x10a320e execute_all_ipa_transforms(bool)
???:0
0xc7b6e8 cgraph_node::expand()
???:0
0xc7d219 symbol_table::compile()
???:0
0xc7fce4 symbol_table::finalize_compilation_unit()
???:0
$ gcc/xg++ -B./gcc -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
[Bug target/112567] [14 regression] ICE in RTL pass: split2: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112567 --- Comment #5 from Sergei Trofimovich --- The fix allowed me to build linux-6.6.1 successfully with current gcc-master. Thank you!
[Bug target/112567] New: [14 regression] ICE in RTL pass: split2: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112567
Bug ID: 112567
Summary: [14 regression] ICE in RTL pass: split2: Segmentation
fault
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed ICE when was building linux-6.6.1 with gcc-master at
r14-5529-g7a496b7ce10518
cvise came up with the following trigger:
// $ cat ast_mode.c.c
union { char b[4]; void (*ul)(void); } gu;
int gv;
void writew(...);
void bug(void) {
struct { char b[2]; } s;
gu.ul = bug;
s.b[0] = gu.b[1] | gv;
writew(s);
}
Crashes as:
$ gcc -O1 -c ast_mode.c.c -o a.o
during RTL pass: split2
ast_mode.c.c: In function 'bug':
ast_mode.c.c:12:1: internal compiler error: Segmentation fault
12 | }
| ^
0x103e83f crash_signal
../../source/gcc/toplev.cc:316
0xbd5d7b mark_label_nuses
../../source/gcc/emit-rtl.cc:3755
0xbd5dcc mark_label_nuses
../../source/gcc/emit-rtl.cc:3763
0xbd5dcc mark_label_nuses
../../source/gcc/emit-rtl.cc:3763
0xbd5ded mark_label_nuses
../../source/gcc/emit-rtl.cc:3766
0xbda6e6 try_split(rtx_def*, rtx_insn*, int)
../../source/gcc/emit-rtl.cc:3952
0xf929d7 split_insn
../../source/gcc/recog.cc:3383
0xf981c7 split_all_insns()
../../source/gcc/recog.cc:3487
0xf98278 execute
../../source/gcc/recog.cc:4411
$ gcc/xgcc -Bgcc -v
Reading specs from gcc/specs
COLLECT_GCC=gcc/xgcc
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 --enable-languages=c
CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0' LDFLAGS='-O1 -g0' : (reconfigured)
/home/slyfox/dev/git/gcc/configure --disable-multilib --disable-bootstrap
--disable-lto --disable-libsanitizer --enable-languages=c CFLAGS='-O1 -g0'
CXXFLAGS='-O1 -g0' LDFLAGS='-O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231116 (experimental) (GCC)
[Bug lto/95194] bootstrap-lto fails on musl (bundled libintl uses asm aliases)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95194 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Sergei Trofimovich --- Sounds good. Let's declared it FIXED for 14.0.
[Bug libstdc++/112467] [14 Regression] libstdc++ fails to build on clang: bits/stl_bvector.h:189:23: error: '__assume__' attribute cannot be applied to a statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112467 --- Comment #2 from Sergei Trofimovich --- Filed a feature request on `clang` side to consider implementing it: https://github.com/llvm/llvm-project/issues/71858 Meanwhile would it be reasonable to enable the attribute only for `gcc`?
[Bug libstdc++/112467] New: [14 Regression] libstdc++ fails to build on clang: bits/stl_bvector.h:189:23: error: '__assume__' attribute cannot be applied to a statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112467 Bug ID: 112467 Summary: [14 Regression] libstdc++ fails to build on clang: bits/stl_bvector.h:189:23: error: '__assume__' attribute cannot be applied to a statement Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Build failure is probably introduced by r14-5260-ge39b3e02c27bd7 and fails on clang-16 as: // $ cat a.cc #include $ clang++ -c a.cc In file included from a.cc:1: In file included from /<>/gcc-14.0.0/include/c++/14.0.0/vector:67: /<>/gcc-14.0.0/include/c++/14.0.0/bits/stl_bvector.h:189:23: error: '__assume__' attribute cannot be applied to a statement __attribute__ ((__assume__ (__ofst < unsigned(_S_word_bit; ^~ 1 error generated. I think it happens because `clang` implements different `assume` attribute compared to `gcc`: https://clang.llvm.org/docs/AttributeReference.html#assume
[Bug bootstrap/112379] [14 Regression] bootstrap failure on --enable-checking=release: gcc/gcc-urlifier.cc:100:1: error: get_url_suffix_for_quoted_text() defined but not used [-Werror=unused-function]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112379 Sergei Trofimovich changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Sergei Trofimovich --- Should be fixed now.
[Bug bootstrap/112379] [14 Regression] bootstrap failure on --enable-checking=release: gcc/gcc-urlifier.cc:100:1: error: get_url_suffix_for_quoted_text() defined but not used [-Werror=unused-function]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112379 --- Comment #1 from Sergei Trofimovich --- Proposed trivial fix by marking helper as `ATTRIBUTE_UNUSED`: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635194.html
[Bug bootstrap/112379] New: [14 Regression] bootstrap failure on --enable-checking=release: gcc/gcc-urlifier.cc:100:1: error: get_url_suffix_for_quoted_text() defined but not used [-Werror=unused-func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112379
Bug ID: 112379
Summary: [14 Regression] bootstrap failure on
--enable-checking=release: gcc/gcc-urlifier.cc:100:1:
error: get_url_suffix_for_quoted_text() defined but
not used [-Werror=unused-function]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed build failure on today's `gcc-master` checkout at
r14-5124-gada871cfadd3f4.
Reproducer:
$ ../gcc/configure --disable-multilib --enable-languages=c,c++
--enable-checking=release
$ make STAGE1_CFLAGS='-O1 -g0'
/tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c
-g -O2 -fno-checking -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -DHAVE_CONFIG_H -fno-PIE -I. -I.
-I/home/slyfox/dev/git/gcc/gcc -I/home/slyfox/dev/git/gcc/gcc/.
-I/home/slyfox/dev/git/gcc/gcc/../include
-I/home/slyfox/dev/git/gcc/gcc/../libcpp/include
-I/home/slyfox/dev/git/gcc/gcc/../libcody
-I/home/slyfox/dev/git/gcc/gcc/../libdecnumber
-I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/slyfox/dev/git/gcc/gcc/../libbacktrace -o gcc-urlifier.o -MT
gcc-urlifier.o -MMD -MP -MF ./.deps/gcc-urlifier.TPo
/home/slyfox/dev/git/gcc/gcc/gcc-urlifier.cc
/home/slyfox/dev/git/gcc/gcc/gcc-urlifier.cc:100:1: error: 'const char*
{anonymous}::gcc_urlifier::get_url_suffix_for_quoted_text(const char*) const'
defined but not used [-Werror=unused-function]
100 | gcc_urlifier::get_url_suffix_for_quoted_text (const char *p) const
| ^~~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:1195: gcc-urlifier.o] Error 1
make[3]: Leaving directory '/tmp/gb/gcc'
make[2]: *** [Makefile:5054: all-stage2-gcc] Error 2
make[2]: Leaving directory '/tmp/gb'
make[1]: *** [Makefile:26048: stage2-bubble] Error 2
make[1]: Leaving directory '/tmp/gb'
make: *** [Makefile:1094: all] Error 2
I suspect it's the effect of r14-5118-gc5db4d8ba5f3de "diagnostics: add
automatic URL-ification within messages".
$ prev-gcc/xg++ -Bprev-gcc -v
Reading specs from prev-gcc/specs
COLLECT_GCC=prev-gcc/xg++
COLLECT_LTO_WRAPPER=prev-gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--enable-languages=c,c++ --enable-checking=release
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231104 (experimental) (GCC)
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347 --- Comment #8 from Sergei Trofimovich --- (In reply to Martin Uecker from comment #6) > Created attachment 56491 [details] > patch > > Ok, let's try again... The change fixes jemalloc and boehm-gc builds for me. Thank you!
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347 --- Comment #2 from Sergei Trofimovich --- A bit of debugging: Program received signal SIGSEGV, Segmentation fault. 0x007bfff6 in convert_for_assignment (location=location@entry=263654, expr_loc=expr_loc@entry=0, type=type@entry=0x7fffea029000, rhs=0x7fffea000508, origtype=origtype@entry=0x0, errtype=errtype@entry=ic_init, null_pointer_constant=false, fundecl=0x0, function=0x0, parmnum=0, warnopt=0) at /home/slyfox/dev/git/gcc/gcc/c/c-typeck.cc:7370 warning: Source file is more recent than executable. 7370 && INTEGER_CST == TREE_CODE (TYPE_SIZE_UNIT (ttl)) (gdb) bt #0 0x007bfff6 in convert_for_assignment (location=location@entry=263654, expr_loc=expr_loc@entry=0, type=type@entry=0x7fffea029000, rhs=0x7fffea000508, origtype=origtype@entry=0x0, errtype=errtype@entry=ic_init, null_pointer_constant=false, fundecl=0x0, function=0x0, parmnum=0, warnopt=0) at /home/slyfox/dev/git/gcc/gcc/c/c-typeck.cc:7370 (gdb) call debug_tree(ttl) >
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347 Sergei Trofimovich changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #1 from Sergei Trofimovich --- r14-5059-gd880e093d92084 "c: Add Walloc-size to warn about insufficient size in allocations [PR71219]" looks relevant.
[Bug c/112347] New: [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
Bug ID: 112347
Summary: [14 regression] ICE on jemalloc-5.3.0: Segmentation
fault around convert_for_assignment()
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed ICE on today's `gcc-master` r14-5073-g36a26298ec7dfc when building
jemalloc-5.3.0. Extracted the following example:
// $ cat a.c.c
int * mallocx(unsigned long) __attribute__((malloc))
__attribute__((alloc_size(1)));
void test_oom(void) { void *a_ = mallocx(1); }
Crashing:
$ gcc/xgcc -Bgcc -std=gnu11 -Wextra -c /tmp/a.c.c
/tmp/a.c.c: In function ‘test_oom’:
/tmp/a.c.c:2:1: internal compiler error: Segmentation fault
2 | void test_oom(void) { void *a_ = mallocx(1); }
| ^~~~
0x225a30b diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x225b12e internal_error(char const*, ...)
???:0
0xee1c4f crash_signal(int)
???:0
0x7bfff6 convert_for_assignment(unsigned int, unsigned int, tree_node*,
tree_node*, tree_node*, impl_conv, bool, tree_node*, tree_node*, int, int)
???:0
0x7cc38d digest_init(unsigned int, tree_node*, tree_node*, tree_node*, bool,
bool, bool, bool, bool, bool)
???:0
0x7cf3af store_init_value(unsigned int, tree_node*, tree_node*, tree_node*)
???:0
0x795284 finish_decl(tree_node*, unsigned int, tree_node*, tree_node*,
tree_node*)
???:0
0x817385 c_parser_declaration_or_fndef(c_parser*, bool, bool, bool, bool, bool,
tree_node**, vec*, bool, tree_node*,
oacc_routine_data*, bool*)
???:0
0x814efb c_parser_compound_statement_nostart(c_parser*)
???:0
0x81573f c_parser_compound_statement(c_parser*, unsigned int*)
???:0
0x81719a c_parser_declaration_or_fndef(c_parser*, bool, bool, bool, bool, bool,
tree_node**, vec*, bool, tree_node*,
oacc_routine_data*, bool*)
???:0
0x821ab9 c_parser_external_declaration(c_parser*)
???:0
0x822610 c_parse_file()
???:0
0x8a274f c_common_parse_file()
???:0
$ gcc/xgcc -Bgcc -v
Reading specs from gcc/specs
COLLECT_GCC=gcc/xgcc
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 --enable-languages=c
CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0' LDFLAGS='-O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231102 (experimental) (GCC)
[Bug bootstrap/111653] make bootstrap4 fails for -fchecking=2 code generation changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111653 Sergei Trofimovich changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Sergei Trofimovich --- The difference on the minimized example from #comment1 disappeared with r14-4793-gdad311874ac3b3 "c++: remove NON_DEPENDENT_EXPR, part 1". On r14-5058-g25f92179dea308 I don't get comparison failures on 'make bootstrap4' anymore. Let's close it as FIXED.
[Bug target/112332] [14 regression] ICE: internal compiler error: in extract_constrain_insn, at recog.cc:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112332 --- Comment #6 from Sergei Trofimovich --- I confirm that the fix also fixes original python-3.11.6 build failure. Thank you!
[Bug target/112332] [14 regression] ICE: internal compiler error: in extract_constrain_insn, at recog.cc:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112332
--- Comment #1 from Sergei Trofimovich ---
Slightly shorter example:
typedef union {
double d;
int L[2];
} U;
void d2b(int*);
void _Py_dg_dtoa(double dd) {
int be;
U u;
u.d = dd;
if (()->L[1])
d2b();
}
[Bug target/112332] New: [14 regression] ICE: internal compiler error: in extract_constrain_insn, at recog.cc:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112332
Bug ID: 112332
Summary: [14 regression] ICE: internal compiler error: in
extract_constrain_insn, at recog.cc:2705
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed ICE today when attempted to build python-3.11.6 with gcc-master
r14-5055-g7480dbb6e7891f.
Extracted reproducer:
// $ cat dtoa.c.c
typedef union {
double d;
int L[2];
} U;
void d2b();
char _Py_dg_dtoa(double dd) {
int be;
U u;
u.d = dd;
if (()->L[1])
d2b();
goto failed_malloc;
goto fast_failed;
goto one_digit;
goto no_digits;
goto ret1;
goto bump_up;
fast_failed:
bump_up:
no_digits:
one_digit:
ret1:
failed_malloc:
return 0;
}
Crashing:
./gcc/xgcc -Bgcc -O2 -fstack-protector-strong dtoa.c.c -o a.o
dtoa.c.c: In function ‘_Py_dg_dtoa’:
dtoa.c.c:25:1: error: insn does not satisfy its constraints:
25 | }
| ^
(insn 51 3 9 2 (parallel [
(set (mem/v/f/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [4 D.2786+0 S8 A64])
(unspec:DI [
(mem/v/f:DI (const_int 40 [0x28]) [5
MEM[( long unsigned int *)40B]+0 S8 A64 AS1])
] UNSPEC_SP_SET))
(set (reg:DI 0 ax [orig:103 dd ] [103])
(reg:DI 20 xmm0 [109]))
]) "dtoa.c.c":10:6 1461 {*stack_protect_set_2_di_di}
(expr_list:REG_DEAD (reg:DI 20 xmm0 [109])
(nil)))
during RTL pass: cprop_hardreg
dtoa.c.c:25:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2705
0x7ef71b _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/slyfox/dev/git/gcc/gcc/rtl-error.cc:108
0x7ef741 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/slyfox/dev/git/gcc/gcc/rtl-error.cc:118
0x7eddcb extract_constrain_insn(rtx_insn*)
/home/slyfox/dev/git/gcc/gcc/recog.cc:2705
0xf60c47 copyprop_hardreg_forward_1
/home/slyfox/dev/git/gcc/gcc/regcprop.cc:836
0xf61d44 execute
/home/slyfox/dev/git/gcc/gcc/regcprop.cc:1423
Compiler:
$ ./gcc/xgcc -Bgcc -v
Reading specs from gcc/specs
COLLECT_GCC=./gcc/xgcc
COLLECT_LTO_WRAPPER=gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-bootstrap
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231101 (experimental) (GCC)
[Bug middle-end/112321] New: [14 Regression] ICE during GIMPLE pass: dse: : Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112321
Bug ID: 112321
Summary: [14 Regression] ICE during GIMPLE pass: dse: :
Segmentation fault
Product: gcc
Version: 14.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: ---
Noticed ICE on today's gcc-master at r14-5043-g2b19c387696b0d. There it fails
to build binutils' gold. Extracted sample:
// $ cat bug.cc
void writeval(unsigned char *, long);
unsigned do_write_count;
void do_write() {
unsigned char *pov;
int limit(do_write_count > 8 ? true : do_write_count);
for (int i = 0; i < limit; ++i)
pov += 2;
int ext_cnt = do_write_count - 8;
for (; 0 < ext_cnt;) {
writeval(pov, 0);
pov += 4;
ext_cnt--;
}
}
Crashing:
$ gcc/xg++ -B./gcc -g -O1 -c bug.cc -o a.o
during GIMPLE pass: dse
bug.cc: In function ‘void do_write()’:
bug.cc:3:6: internal compiler error: Segmentation fault
3 | void do_write() {
| ^~~~
0x8ebef5a crash_signal
gcc/toplev.cc:315
0x8b42800 phi_nodes_ptr(basic_block_def*)
gcc/gimple.h:4700
0x8b42800 gsi_start_phis(basic_block_def*)
gcc/gimple-iterator.cc:935
0x8b42800 gsi_for_stmt(gimple*)
gcc/gimple-iterator.cc:620
0x9121a03 insert_debug_temp_for_var_def(gimple_stmt_iterator*, tree_node*)
gcc/tree-ssa.cc:471
0x9121f2e insert_debug_temps_for_defs(gimple_stmt_iterator*)
gcc/tree-ssa.cc:506
0x8b42690 gsi_remove(gimple_stmt_iterator*, bool)
gcc/gimple-iterator.cc:567
0x8ffe08b execute
gcc/tree-ssa-dse.cc:1685
$ gcc/xg++ -Bgcc -v
Reading specs from ./gcc/specs
COLLECT_GCC=./gcc/xg++
COLLECT_LTO_WRAPPER=./gcc/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231031 (experimental) (GCC)
[Bug rtl-optimization/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs since r14-4944-gf55cdce3f8dd85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 Sergei Trofimovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Sergei Trofimovich --- The change fixed bootstrap for me. Thank you! Let's declare it fixed.
[Bug rtl-optimization/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 --- Comment #8 from Sergei Trofimovich --- bootstrap with default options did not fail for me either. I had to use --enable-checking=release to trigger the failure. I wonder if it exposes the failure for you as well.
[Bug rtl-optimization/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 --- Comment #6 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #5) > Bisected down to r14-4943-g8d2130a4e5ce36 "[RA]: Modfify cost calculation > for dealing with equivalences" Sorry, pasted wrong hash. That should be a r14-4944-gf55cdce3f8dd85 "[RA]: Modfify cost calculation for dealing with equivalences"
[Bug rtl-optimization/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 Sergei Trofimovich changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org, ||vmakarov at redhat dot com --- Comment #5 from Sergei Trofimovich --- Bisected down to r14-4943-g8d2130a4e5ce36 "[RA]: Modfify cost calculation for dealing with equivalences"
[Bug bootstrap/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107
--- Comment #2 from Sergei Trofimovich ---
Reduced ira-build.cc down to the following:
// $ cat pp.cc.cc
typedef struct ira_object *ira_object_t;
struct ira_object {
void *conflicts_array;
int min, max;
};
void *ira_allocate(int);
int ira_conflict_vector_profitable_p_nbytes;
void ira_conflict_vector_profitable_p(ira_object_t obj) {
int max(obj->max);
if (max < obj->min)
ira_conflict_vector_profitable_p_nbytes = max - obj->min;
}
void ira_allocate_object_conflicts(ira_object_t obj) {
ira_conflict_vector_profitable_p(obj);
int size((obj->max - obj->min) * sizeof 0);
obj->conflicts_array = ira_allocate(size);
}
Reproducer:
# cat trigger.bash
#!/usr/bin/env bash
f() {
stage3-gcc/xg++ -Bstage3-gcc -nostdinc++ -fno-PIE -g -O2 -fchecking=1
-DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-PIE -c
pp.cc.cc -o pp.o -Wall "$@"
strip --strip-debug pp.o
sha1sum pp.o
}
[[ "$(f)" == "$(f -gtoggle)" ]] && echo EQUAL || echo DIFF
Running:
$ ./trigger.bash
DIFF
[Bug bootstrap/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 --- Comment #1 from Sergei Trofimovich --- `diffoscope` says there is a difference in generated code in one of the functions: $ strip --strip-debug stage2-gcc-ira-build.o stage3-gcc-ira-build.o $ diffoscope stage2-gcc-ira-build.o stage3-gcc-ira-build.o │ add$0x10,%esp │ mov$0x1,%edx │ mov%eax,0x4(%esi) │ movl $0x0,(%eax) │ movl $0x0,0x38(%esi) │ - jmp363b │ - lea0x0(%esi,%eiz,1),%esi │ - lea0x0(%esi),%esi │ + jmp363c │ + xchg %ax,%ax
[Bug bootstrap/112107] New: [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 Bug ID: 112107 Summary: [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Noticed on this week's build on i686-unknown-linux-gnu build/host/target. How to reproduce against r14-4967-g8697d3a1dcf327: $ ../gcc/configure --disable-multilib --enable-languages=c,c++ --enable-languages=c,c++ --enable-checking=release $ make STAGE1_CFLAGS=-O2 ... Comparing stages 2 and 3 Bootstrap comparison failure! gcc/ira-build.o differs $ stage3-gcc/xgcc -Bstage3-gcc -v Reading specs from stage3-gcc/specs COLLECT_GCC=stage3-gcc/xgcc COLLECT_LTO_WRAPPER=stage3-gcc/lto-wrapper Target: i686-pc-linux-gnu Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ --enable-checking=release Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20231027 (experimental) (GCC)
[Bug libstdc++/111824] [14 Regression] is invalid under -U__STRICT_ANSI__ -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111824 --- Comment #2 from Sergei Trofimovich --- Sounds good.
[Bug libstdc++/111824] New: [14 Regression] is invalid under -U__STRICT_ANSI__ -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111824 Bug ID: 111824 Summary: [14 Regression] is invalid under -U__STRICT_ANSI__ -std=c++11 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- I think it's a regression started from r14-1433-gf150a084e25eaa Noticed on `monotone-1.1` source code where `monotone` uses `#undef __STRICT_ANSI__` for some reason. As a result build fails as: $ printf "#include " | g++ -c -x c++ - -U__STRICT_ANSI__ -std=c++11 -o /dev/null |& head -n 10 In file included from /<>/gcc-14.0.0/include/c++/14.0.0/limits:42, from :1: /<>/gcc-14.0.0/include/c++/14.0.0/x86_64-unknown-linux-gnu/bits/c++config.h:668:2: warning: #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported" [-Wcpp] 668 | #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported" | ^~~ /<>/gcc-14.0.0/include/c++/14.0.0/limits:2100:30: error: exponent has no digits 2100 | return __extension__ 0x1.0p-16382Q; | ^~ /<>/gcc-14.0.0/include/c++/14.0.0/limits:2114:30: error: exponent has no digits 2114 | return __extension__ 0x1.p+16383Q; AFAIU it's caused by the code like #ifdef __STRICT_ANSI__ // 0x1.0p-30 * 0x1.0p-16352 return double(9.3132257461547852e-10) * _S_1pm16352(); #else return __extension__ 0x1.0p-16382Q; #endif Note that -std=gnu++11 does work. I'm not sure if it's a user error to unset `__STRICT_ANSI__` and expect libstdc++ to use only supported extensions. Filing the bug just in case.
[Bug bootstrap/111663] profiledbootstrap fails on master: gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111663 Sergei Trofimovich changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |slyfox at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Sergei Trofimovich --- Fixed in master branch.
[Bug ipa/111283] [14 Regression] gnat profilebootstrap broken on trunk 20230902 on 32bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283 Sergei Trofimovich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |slyfox at gcc dot gnu.org --- Comment #11 from Sergei Trofimovich --- Should be fixed in master. Thank you for the report!
[Bug gcov-profile/111559] [14 regression] ICE when building Python with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559 Sergei Trofimovich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |slyfox at gcc dot gnu.org --- Comment #10 from Sergei Trofimovich --- Fixed in master. Thanks for the report!
[Bug bootstrap/111663] profiledbootstrap fails on master: gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111663 --- Comment #1 from Sergei Trofimovich --- Proposed the change as https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631790.html
[Bug bootstrap/111663] New: profiledbootstrap fails on master: gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111663 Bug ID: 111663 Summary: profiledbootstrap fails on master: gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- It is the same issue diagnosed by Martin in https://gcc.gnu.org/PR87932#c2 The only difference here is the failure of profiledbootstrap on master by default (until you disable -Werror). The reproducer: $ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ CC='gcc -O2' CXX='g++ -O2' $ make profiledbootstrap ... gcc/gcc/sort.cc: In function ‘void reorder45(sort_ctx*, char*, char*, char*, char*, char*) [with sort_ctx = sort_r_ctx]’: gcc/gcc/sort.cc:313:1: error: ‘gcc/build/sort.gcda’ profile count data file not found [-Werror=missing-profile] 313 | } | ^ gcc/gcc/genmodes.cc: In function ‘int main(int, char**)’: gcc/gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile] 2152 | } | ^ gcc/gcc/gengtype-parse.cc: In function ‘void parse_file(const char*)’: gcc/gcc/gengtype-parse.cc:1186:1: error: ‘gcc/build/gengtype-parse.gcda’ profile count data file not found [-Werror=missing-profile] 1186 | } | ^ cc1plus: all warnings being treated as errors make[3]: *** [Makefile:2949: build/gengenrtl.o] Ошибка 1 gcc/gcc/gengtype-parse.cc: In function ‘void parse_error(const char*, ...)’: gcc/gcc/gengtype-parse.cc:142:21: error: ‘%s’ directive argument is null [-Werror=format-overflow=] 142 | fprintf (stderr, "%s:%d: parse error: ", | ^~ Stable branches work just because -Werror is disabled. Note that autofeedback has a similar problem and it works it around with disabling -Werror: # Disable warnings as errors since inlining decisions with -fauto-profile # may result in additional warnings. STAGEautofeedback_CONFIGURE_FLAGS = $(filter-out --enable-werror-always,$(STAGE_CONFIGURE_FLAGS)) I suggest doling the same for `profiledbootstrap` as: --- a/Makefile.tpl +++ b/Makefile.tpl @@ -561,6 +561,10 @@ STAGEtrain_TFLAGS = $(filter-out -fchecking=1,$(STAGE3_TFLAGS)) STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use -fprofile-reproducible=parallel-runs STAGEfeedback_TFLAGS = $(STAGE4_TFLAGS) +# Disable warnings as errors for a few reasons: +# - sources for gen* binaries do not have .gcda files available +# - inlining decisions generate extra warnings +STAGEfeedback_CONFIGURE_FLAGS = $(filter-out --enable-werror-always,$(STAGE_CONFIGURE_FLAGS)) STAGEautoprofile_CFLAGS = $(filter-out -gtoggle,$(STAGE2_CFLAGS)) -g STAGEautoprofile_TFLAGS = $(STAGE2_TFLAGS)
[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642 --- Comment #14 from Sergei Trofimovich --- (In reply to Richard Sandiford from comment #13) > Created attachment 56023 [details] > Tentative fix Re " That now triggers a warning in some configurations, since the NUM_POLY_INT_COEFFS>1 tests used the global poly_int64, whose definition does not depend on the template parameter." Minor note: it's a type error for clang++ and g++ -fchecking=2, not just a warning. I think both gcc and clang do reject the code as they see a type mismatch in `poly_int64<1, T>(1,1)` call. Otherwise the fix works for me and passes `make bootstrap4`. Thank you!
[Bug bootstrap/111653] New: make bootstrap4 fails for -fchecking=2 code generation changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111653
Bug ID: 111653
Summary: make bootstrap4 fails for -fchecking=2 code generation
changes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Reproducer on current gcc master from r14-4353-gf416a3fdbee32a:
$ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++
CC='gcc -O2' CXX='g++ -O2'
$ make bootstrap4
...
Comparing stages 3 and 4
Bootstrap comparison failure!
x86_64-pc-linux-gnu/libstdc++-v3/src/filesystem/dir.o differs
x86_64-pc-linux-gnu/libstdc++-v3/src/filesystem/cow-dir.o differs
x86_64-pc-linux-gnu/libstdc++-v3/src/c++20/tzdb.o differs
x86_64-pc-linux-gnu/libstdc++-v3/src/c++17/cow-fs_path.o differs
x86_64-pc-linux-gnu/libstdc++-v3/src/c++17/fs_path.o differs
x86_64-pc-linux-gnu/libstdc++-v3/src/c++17/cow-fs_dir.o differs
x86_64-pc-linux-gnu/libstdc++-v3/src/c++17/fs_dir.o differs
The failure happens due to the difference between stage3 and stage4 flags:
- stage3: -fchecking=1
- stage4: no flag (debug version implies -fchecking=2 due to
`ac_checking_flags=yes,extra` non-release defaults)
Som thoughts:
1. gcc manual says it's fine to see minor code geneation changes on
-fchecking=2.
2. there are only 7 files with code generation difference
3. -fchecking=2 detects real bugs like PR111647
It feels like depending on [1.] being a bug or a feature there are a few
possible solutions:
a) fix -fchecking=2 instability and change manual to always guarantee that
-fchecking=2 does not change code
b) if a) is infeasible then stop using -fchecking=2 for stage compares, say to
disable do-compare3 entirely
c) declate 4-stage bootstrap incompatible with `extra` checking flags
d) something else?
WDYT?
Minimal example with -fchecking= instability:
$ cat fs_dir.cc.cc
namespace std {
struct type_info {
void operator==(const type_info &) const;
};
struct _Sp_counted_base {
virtual void _M_get_deleter(const type_info &);
};
struct _Sp_make_shared_tag {};
template struct _Sp_counted_ptr_inplace : _Sp_counted_base {
struct _Impl {
_Impl(int);
};
_Sp_counted_ptr_inplace(int __a) : _M_impl(__a) {}
void _M_get_deleter(const type_info &__ti) {
__ti == typeid(_Sp_make_shared_tag);
}
_Impl _M_impl;
};
struct __shared_count {
__shared_count() { _Sp_counted_ptr_inplace(0); }
} _M_refcount;
} // namespace std
$ g++ -frandom-seed=fs_dir.lo -c fs_dir.cc.cc -fchecking=2 -o bug.o
$ sha1sum bug.o
92d676d60ee6e26e9b242fb64bffe9e47a92052a bug.o
$ /g++ -frandom-seed=fs_dir.lo -c fs_dir.cc.cc -fchecking=2 -o bug.o
-fchecking=1
$ sha1sum bug.o
748b578657a335c212872b012b2afaf0be3ecbc4 bug.o
Note: hashes are different.
$ stage4-gcc/xgcc -Bstage4-gcc -v
Reading specs from stage4-gcc/specs
COLLECT_GCC=stage4-gcc/xgcc
COLLECT_LTO_WRAPPER=stage4-gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--enable-languages=c,c++ CC='gcc -O2' CXX='g++ -O2'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230929 (experimental) (GCC)
[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642 Sergei Trofimovich changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Sergei Trofimovich --- Proposed the possible fix as https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631739.html It #ifdefs out any attempts to create multi-coefficient polynomials on the system with a single polynomial like `poly_int<1, T>(1, 1)`.
[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642 --- Comment #8 from Sergei Trofimovich --- With https://gcc.gnu.org/PR111647#c1 I'm convinced it's a gcc's source code bug and we should not try to write calls like `poly_int<1, T>(1, 1)` with mismatching arity.
[Bug c++/111647] g++ accepts different c++ on -fchecking= anf checking=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111647
--- Comment #1 from Sergei Trofimovich ---
More realistic example extracted from gcc's poly_int:
// $ cat rtl-tests.cc
template struct poly_int {
template constexpr poly_int (const Cs &... cs)
: coeffs { cs... } {}
int coeffs[N];
};
#define TARGET_DEFINED_VALUE 1
// this works:
//#define TARGET_DEFINED_VALUE 2
// Is instantiated only for N == 2.
template struct const_poly_int_tests {
static void run () {
poly_int (1, 1);
}
};
$ g++ -c rtl-tests.cc -fchecking=1
# did not fail, BAD!
$ g++ -c rtl-tests.cc -fchecking=2
rtl-tests.cc: In instantiation of 'constexpr poly_int::poly_int(const Cs&
...) [with Cs = {int, int}; unsigned int N = 1]':
rtl-tests.cc:15:42: required from here
rtl-tests.cc:3:5: error: too many initializers for 'int [1]'
3 | : coeffs { cs... } {}
| ^~~~
# failed, GOOD
$ clang++ -c rtl-tests.cc
rtl-tests.cc:3:14: error: excess elements in array initializer
: coeffs { cs... } {}
^~
rtl-tests.cc:15:5: note: in instantiation of function template specialization
'poly_int<1>::poly_int' requested here
poly_int (1, 1);
^
1 error generated.
# failed, GOOD
[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
--- Comment #7 from Sergei Trofimovich ---
If I try to build the file with `clang++-16` I'm getting the following error:
In file included from /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:22:
In file included from /home/slyfox/dev/git/gcc/gcc/coretypes.h:480:
/home/slyfox/dev/git/gcc/gcc/poly-int.h:453:14: error: excess elements in array
initializer
: coeffs { (typename poly_coeff_traits::
^~~~
/home/slyfox/dev/git/gcc/gcc/poly-int.h:438:5: note: in instantiation of
function template specialization 'poly_int<1, long>::poly_int'
requested here
: poly_int (typename poly_int_fullness= N>::type (),
^
/home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:249:26: note: in instantiation of
function template specialization 'poly_int<1, long>::poly_int'
requested here
rtx x1 = gen_int_mode (poly_int64 (1, 1), QImode);
^
Which sounds like we should not try to create polynomials with values more than
`NUM_POLY_INT_COEFFS` (== 1 on x86_64).
I'm still not sure if the templates are expected to defer build failure in this
case or it's a c++ syntax error in gcc's code.
[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
Sergei Trofimovich changed:
What|Removed |Added
Depends on||111647
--- Comment #6 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #5)
> I'll try to extract smaller example.
Got the following, but I'm not sure it's valid C++:
struct poly_int {
template constexpr poly_int() : poly_int() {}
};
template void run() { poly_int(); }
Filed PR111647 and will try to extract something less invalid.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111647
[Bug 111647] g++ accepts different c++ on -fchecking= anf checking=2
[Bug c++/111647] New: g++ accepts different c++ on -fchecking= anf checking=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111647
Bug ID: 111647
Summary: g++ accepts different c++ on -fchecking= anf
checking=2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Encountered when was reducing PR111642 where `make bootstrap4` fails. Reduced
example:
// $ cat rtl-tests.cc.cc
struct poly_int {
template constexpr poly_int() : poly_int() {}
};
template void run() { poly_int(); }
Here is the mismatch between -fchecking=0 and -fchecking=2:
$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -c rtl-tests.cc.cc -o bug
-fchecking=0
$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -c rtl-tests.cc.cc -o bug
-fchecking=2
rtl-tests.cc.cc: In instantiation of ‘constexpr poly_int::poly_int() [with
= {}]’:
rtl-tests.cc.cc:4:39: required from here
rtl-tests.cc.cc:2:58: error: constructor delegates to itself
2 | template constexpr poly_int() : poly_int() {}
|
I think it's an invalid code (clang rejects it as well), but I'm not sure.
AFAIU all -fchecking= options should handle it identically.
gcc is from r14-4339-geaa41a6dc127d8
$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -v
Reading specs from /tmp/gb/./prev-gcc/specs
COLLECT_GCC=/tmp/gb/./prev-gcc/xg++
COLLECT_LTO_WRAPPER=/tmp/gb/./prev-gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--enable-languages=c,c++ CC='gcc -O1 -g0' CXX='g++ -O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230929 (experimental) (GCC)
[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
--- Comment #5 from Sergei Trofimovich ---
The default value is `-fchecking=2` there. `-fchecking=0` and `-fchecking=1`
work fine. This means `-fchecking=` slightly alters c++ template instantiation.
I'll try to extract smaller example.
The following workaround seems to restore the build:
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -29302,20 +29302,21 @@ tree
build_non_dependent_expr (tree expr)
{
tree orig_expr = expr;
tree inner_expr;
/* When checking, try to get a constant value for all non-dependent
expressions in order to expose bugs in *_dependent_expression_p
and constexpr. This can affect code generation, see PR70704, so
only do this for -fchecking=2. */
if (flag_checking > 1
+ && false
&& cxx_dialect >= cxx11
/* Don't do this during nsdmi parsing as it can lead to
unexpected recursive instantiations. */
&& !parsing_nsdmi ()
/* Don't do this during concept processing either and for
the same reason. */
&& !processing_constraint_expression_p ())
fold_non_dependent_expr (expr, tf_none);
STRIP_ANY_LOCATION_WRAPPER (expr);
[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
--- Comment #4 from Sergei Trofimovich ---
Looks like `-fchecking=1` and `-fno-checking` handle c++ a bit differently.
Two commands differing only in `-fno-checking`. One works, one does not:
```
$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c
-g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-DHAVE_CONFIG_H -fno-PIE -I. -I. -I/home/slyfox/dev/git/gcc/gcc
-I/home/slyfox/dev/git/gcc/gcc/. -I/home/slyfox/dev/git/gcc/gcc/../include
-I/home/slyfox/dev/git/gcc/gcc/../libcpp/include
-I/home/slyfox/dev/git/gcc/gcc/../libcody
-I/home/slyfox/dev/git/gcc/gcc/../libdecnumber
-I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/slyfox/dev/git/gcc/gcc/../libbacktrace -o rtl-tests.o -MT rtl-tests.o
-MMD -MP -MF ./.deps/rtl-tests.TPo /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc
In file included from /home/slyfox/dev/git/gcc/gcc/coretypes.h:480,
from /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:22:
/home/slyfox/dev/git/gcc/gcc/poly-int.h: In instantiation of 'constexpr
poly_int::poly_int(poly_int_full, const Cs& ...) [with Cs = {int, int};
unsigned int N = 1; C = long int]':
/home/slyfox/dev/git/gcc/gcc/poly-int.h:439:13: required from here
/home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:249:25: in 'constexpr' expansion of
'poly_int<1, long int>(1, 1)'
/home/slyfox/dev/git/gcc/gcc/poly-int.h:453:5: error: too many initializers for
'long int [1]'
453 | : coeffs { (typename poly_coeff_traits::
| ^
454 | template init_cast::type (cs))... } {}
| ~~~
# fails
```
```
$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c
-g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-DHAVE_CONFIG_H -fno-PIE -I. -I. -I/home/slyfox/dev/git/gcc/gcc
-I/home/slyfox/dev/git/gcc/gcc/. -I/home/slyfox/dev/git/gcc/gcc/../include
-I/home/slyfox/dev/git/gcc/gcc/../libcpp/include
-I/home/slyfox/dev/git/gcc/gcc/../libcody
-I/home/slyfox/dev/git/gcc/gcc/../libdecnumber
-I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/slyfox/dev/git/gcc/gcc/../libbacktrace -o rtl-tests.o -MT rtl-tests.o
-MMD -MP -MF ./.deps/rtl-tests.TPo /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc
-fno-checking
# ok
```
[Bug bootstrap/111642] [14 Regression] bootstrap4 or profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642 Sergei Trofimovich changed: What|Removed |Added Summary|[14 Regression] |[14 Regression] bootstrap4 |profiledbootstrap failure: |or profiledbootstrap |poly-int.h:453:5: error:|failure: poly-int.h:453:5: |too many initializers for |error: too many |‘long int [1]’ (possibly|initializers for ‘long int |since |[1]’ (possibly since |r14-4339-geaa41a6dc127d8) |r14-4339-geaa41a6dc127d8) --- Comment #3 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #0) > To reproduce: > > $ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ > CC='gcc -O1 -g0' CXX='g++ -O1 -g0' > $ make -j16 profiledbootstrap Minor note: it has something to do with 4-stage bootstrap (which profiledbootstrap also happens to be). `make bootstrap4` fails the same way.
[Bug bootstrap/111642] [14 Regression] profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642 --- Comment #1 from Sergei Trofimovich --- Looks like this code is all under `#if CHECKING_P` of sorts. A few more possibly affected entries: ``` $ git grep -P 'poly_int64 \(\d+, \d+\)' gcc/config/riscv/riscv-selftests.cc: -BYTES_PER_RISCV_VECTOR * 33, poly_int64 (207, 0), gcc/config/riscv/riscv-selftests.cc: poly_int64 (-207, 0), poly_int64 (0, 207), gcc/config/riscv/riscv-selftests.cc: poly_int64 (0, -207), poly_int64 (, 0), gcc/config/riscv/riscv-selftests.cc: poly_int64 (0, ), poly_int64 (4096, 4096), gcc/config/riscv/riscv-selftests.cc: poly_int64 (17, 4088), poly_int64 (3889, 4104), gcc/config/riscv/riscv-selftests.cc: poly_int64 (9317, -88), poly_int64 (4, 4), gcc/config/riscv/riscv-selftests.cc: poly_int64 (17, 4), poly_int64 (-7337, 4), gcc/config/riscv/riscv-selftests.cc: poly_int64 (219, -1508), poly_int64 (2, 2), gcc/config/riscv/riscv-selftests.cc: poly_int64 (33, 2), poly_int64 (-7337, 2), gcc/config/riscv/riscv-selftests.cc: poly_int64 (945, -954), poly_int64 (1, 1), gcc/config/riscv/riscv-selftests.cc: poly_int64 (977, 1), poly_int64 (-339, 1), gcc/config/riscv/riscv-selftests.cc: poly_int64 (44, -1), poly_int64 (9567, 77), gcc/config/riscv/riscv.cc: return poly_int64 (1, 1); gcc/rtl-tests.cc: rtx x1 = gen_int_mode (poly_int64 (1, 1), QImode); gcc/rtl-tests.cc: rtx x255 = gen_int_mode (poly_int64 (1, 255), QImode); gcc/rtl-tests.cc: ASSERT_EQ (x1, gen_int_mode (poly_int64 (1, 1), QImode)); gcc/rtl-tests.cc: ASSERT_NE (x1, gen_int_mode (poly_int64 (1, 1), HImode)); gcc/rtl-tests.cc: ASSERT_KNOWN_EQ (const_poly_int_value (x1), poly_int64 (1, 1)); gcc/rtl-tests.cc: ASSERT_KNOWN_EQ (rtx_to_poly_int64 (x1), poly_int64 (1, 1)); gcc/rtl-tests.cc: ASSERT_MAYBE_NE (rtx_to_poly_int64 (x255), poly_int64 (1, 255)); gcc/rtl-tests.cc: rtx offset1 = gen_int_mode (poly_int64 (9, 11), Pmode); gcc/rtl-tests.cc: ASSERT_RTX_EQ (plus_constant (Pmode, symbol, poly_int64 (9, 11)), sum1); gcc/rtl-tests.cc: rtx offset2 = gen_int_mode (poly_int64 (12, 20), Pmode); gcc/rtl-tests.cc: ASSERT_RTX_EQ (plus_constant (Pmode, sum1, poly_int64 (3, 9)), sum2); gcc/simplify-rtx.cc: rtx x1 = gen_int_mode (poly_int64 (1, 1), QImode); gcc/simplify-rtx.cc: rtx x4 = gen_int_mode (poly_int64 (5, 4), QImode); gcc/simplify-rtx.cc: rtx x5 = gen_int_mode (poly_int64 (30, 24), QImode); gcc/simplify-rtx.cc: rtx x6 = gen_int_mode (poly_int64 (20, 16), QImode); gcc/simplify-rtx.cc: rtx x7 = gen_int_mode (poly_int64 (7, 4), QImode); gcc/simplify-rtx.cc: rtx x8 = gen_int_mode (poly_int64 (30, 24), HImode); ```
[Bug bootstrap/111642] New: [14 Regression] profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
Bug ID: 111642
Summary: [14 Regression] profiledbootstrap failure:
poly-int.h:453:5: error: too many initializers for
‘long int [1]’ (possibly since
r14-4339-geaa41a6dc127d8)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
I suspect r14-4339-geaa41a6dc127d8 "Remove poly_int_pod" caused checking build
failure as:
In file included from /home/slyfox/dev/git/gcc/gcc/coretypes.h:480,
from /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:22:
/home/slyfox/dev/git/gcc/gcc/poly-int.h: In instantiation of ‘constexpr
poly_int::poly_int(poly_int_full, const Cs& ...) [with Cs = {int, int};
unsigned int N = 1; C = long int]’:
/home/slyfox/dev/git/gcc/gcc/poly-int.h:439:13: required from here
/home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:249:25: in ‘constexpr’ expansion of
‘poly_int<1, long int>(1, 1)’
/home/slyfox/dev/git/gcc/gcc/poly-int.h:453:5: error: too many initializers for
‘long int [1]’
453 | : coeffs { (typename poly_coeff_traits::
| ^
454 | template init_cast::type (cs))... } {}
| ~~~
make[3]: *** [Makefile:1188: rtl-tests.o] Error 1
To reproduce:
$ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ CC='gcc
-O1 -g0' CXX='g++ -O1 -g0'
$ make -j16 profiledbootstrap
$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -v
Reading specs from /tmp/gb/./prev-gcc/specs
COLLECT_GCC=/tmp/gb/./prev-gcc/xg++
COLLECT_LTO_WRAPPER=/tmp/gb/./prev-gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--enable-languages=c,c++ CC='gcc -O1 -g0' CXX='g++ -O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230929 (experimental) (GCC)
[Bug other/86656] [meta-bug] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 111505, which changed state. Bug 111505 Summary: [14 Regression] Asan (address-sanitizer) bootstrap fails since r14-4003-geaa8e8541349df https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111505 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/111505] [14 Regression] Asan (address-sanitizer) bootstrap fails since r14-4003-geaa8e8541349df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111505 Sergei Trofimovich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |slyfox at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Sergei Trofimovich --- I can confirm --with-build-config=bootstrap-asan fails the same way before the fix and passes successfully after the fix. Let's declare it FIXED.
[Bug middle-end/111505] [14 Regression] Asan (address-sanitizer) bootstrap fails since r14-4003-geaa8e8541349df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111505 --- Comment #5 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #4) > Is it a ggc_common_finalize() bug in assuming that `base` does not point to > the bbeginning of a struct? > Or a `gt_ggc_r_gt_cp_tree_h` bug that it does not point to the beginning of > the struct? > > Also while at it: what should `ggc_common_finalize ()` ideally do to > `ovl_op_info`? memset() all of it? Or only pointers? I think it has > information only to do latter but it does it in a very strange way. Proposed fix as https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631634.html . That fixes `profiledbootstrap` for me. Having stared a bit more at gcc/ggc-common.cc the answer is: it's complicated. There are 3 roots: gt_ggc_rtab gt_ggc_deletable_rtab gt_pch_scalar_rtab Last two are simple: these are single-element complete values without complexities. But gt_ggc_rtab is different: it encodes pointer locations within structs (of non-pointers). GCH code carefully extracts and restores those pointers. An example: for (rt = gt_ggc_rtab; *rt; rt++) for (rti = *rt; rti->base != NULL; rti++) for (i = 0; i < rti->nelt; i++) (*rti->pchw)(*(void **)((char *)rti->base + rti->stride * i)); finalize() should do the same.
[Bug middle-end/111505] [14 Regression] Asan (address-sanitizer) bootstrap fails since r14-4003-geaa8e8541349df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111505
--- Comment #4 from Sergei Trofimovich ---
In https://gcc.gnu.org/PR111629#c0 profiled bootstrap fales for a similar
reason.
There ggc_common_finalize() memset()s unexpected memory location
#1 0x01933651 in ggc_common_finalize () at
/home/slyfox/dev/git/gcc/gcc/ggc-common.cc:1312
1312 memset (rti->base, 0, rti->stride * rti->nelt);
(gdb) list
1307for (rti = *rt; rti->base != NULL; rti++)
1308 memset (rti->base, 0, rti->stride * rti->nelt);
1309
1310 for (rt = gt_ggc_rtab; *rt; rt++)
1311for (rti = *rt; rti->base != NULL; rti++)
1312 memset (rti->base, 0, rti->stride * rti->nelt);
for this global:
struct GTY(()) ovl_op_info_t {
/* The IDENTIFIER_NODE for the operator. */
tree identifier;
/* The name of the operator. */
const char *name;
/* The mangled name of the operator. */
const char *mangled_name;
/* The (regular) tree code. */
enum tree_code tree_code : 16;
/* The (compressed) operator code. */
enum ovl_op_code ovl_op_code : 8;
/* The ovl_op_flags of the operator */
unsigned flags : 8;
};
/* Overloaded operator info indexed by ass_op_p & ovl_op_code. */
extern GTY(()) ovl_op_info_t ovl_op_info[2][OVL_OP_MAX];
Generated tables:
/* Structures for the easy way to mark roots.
In an array, terminated by having base == NULL. */
struct ggc_root_tab {
void *base;
size_t nelt;
size_t stride;
gt_pointer_walker cb;
gt_pointer_walker pchw;
};
EXPORTED_CONST struct ggc_root_tab gt_ggc_r_gt_cp_tree_h[] = {
...
{ // 4
_op_info[0][0].identifier,
1 * (2) * (OVL_OP_MAX),
sizeof (ovl_op_info[0][0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
{ // 5
_op_info[0][0].name,
1 * (2) * (OVL_OP_MAX),
sizeof (ovl_op_info[0][0]),
(gt_pointer_walker) _ggc_m_S,
(gt_pointer_walker) _pch_n_S
},
{ //6
_op_info[0][0].mangled_name,
1 * (2) * (OVL_OP_MAX),
sizeof (ovl_op_info[0][0]),
(gt_pointer_walker) _ggc_m_S,
(gt_pointer_walker) _pch_n_S
},
Is it a ggc_common_finalize() bug in assuming that `base` does not point to the
bbeginning of a struct?
Or a `gt_ggc_r_gt_cp_tree_h` bug that it does not point to the beginning of the
struct?
Also while at it: what should `ggc_common_finalize ()` ideally do to
`ovl_op_info`? memset() all of it? Or only pointers? I think it has information
only to do latter but it does it in a very strange way.
[Bug other/111629] New: [14 Regression] ggc_common_finalize() corrupts global memory outsuide GTY(()) objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111629
Bug ID: 111629
Summary: [14 Regression] ggc_common_finalize() corrupts global
memory outsuide GTY(()) objects
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially I observed the bug as a gcc profiled bootstrap failure on
r14-4300-g1fab05a885a308:
$ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ 'CC=gcc
-O2 -ggdb3' 'CXX=g++ -O2 -ggdb3'
$ make profiledbootstrap
configure: error: uint64_t or int64_t not found
$ touch a.c && /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -c a.c
xg++: internal compiler error: Segmentation fault signal terminated program
cc1plus
While it look slike a profile-related problem I think it's just a coincidence:
it's a side-effect of gcov globals corruption exposed by
`ggc_common_finalize()`.
`ggc_common_finalize()` is supposed to memset() GTY(()) globals, but its
slightly out of bounds and corrupts gcov.
Debugging:
$ gdb --args /tmp/gb/./prev-gcc/cc1plus -quiet -v -iprefix
/tmp/gb/prev-gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/ -isystem
/tmp/gb/./prev-gcc/include -isystem /tmp/gb/./prev-gcc/include-fixed
-D_GNU_SOURCE a.c -quiet -dumpbase a.c -dumpbase-ext .c -mtune=generic
-march=x86-64 -version -o /run/user/1000/ccA6Gln1.s
(gdb) run
...
Program received signal SIGSEGV, Segmentation fault.
0x0442ab26 in gcov_do_dump (list=0x5cab0e0, run_counted=0, mode=0) at
/home/slyfox/dev/git/gcc/libgcc/libgcov-driver.c:690
690 for (unsigned i = 0; i < cinfo->num; i++)
(gdb) list
685 for (unsigned f_ix = 0; (unsigned)f_ix != gi_ptr->n_functions;
f_ix++)
686 {
687 const struct gcov_ctr_info *cinfo
688 = _ptr->functions[f_ix]->ctrs[GCOV_COUNTER_ARCS];
(gdb) p gi_ptr->functions[f_ix]
$1 = (const gcov_fn_info * const) 0x0
=== This is a corruption: `gi_ptr->functions[f_ix]` are gcov.* global
counters.
=== They are never expected to be zero. Looking up place of corruption:
(gdb) p _ptr->functions[f_ix]
$2 = (const gcov_fn_info * const *) 0x50c1540
(gdb) watch -l *(void**)0x50c1540
Hardware watchpoint 1: -location *(void**)0x50c1540
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Hardware watchpoint 1: -location *(void**)0x50c1540
Old value = (void *) 0x50c4080
<__gcov_._ZN10hash_tableI18subsumption_hasherLb0E11xcallocatorE26find_empty_slot_for_expandEj>
New value = (void *) 0x50c4000
__memset_avx2_unaligned_erms () at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:328
328 ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No such file
or directory.
(gdb) bt
#0 __memset_avx2_unaligned_erms () at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:328
#1 0x01933651 in ggc_common_finalize () at
/home/slyfox/dev/git/gcc/gcc/ggc-common.cc:1312
#2 0x020d7cf1 in toplev::finalize (this=this@entry=0x7fffaece) at
/home/slyfox/dev/git/gcc/gcc/toplev.cc:2354
#3 0x00c640b6 in main (argc=, argv=0x7fffaff8) at
/home/slyfox/dev/git/gcc/gcc/main.cc:42
(gdb) fr 1
#1 0x01933651 in ggc_common_finalize () at
/home/slyfox/dev/git/gcc/gcc/ggc-common.cc:1312
1312 memset (rti->base, 0, rti->stride * rti->nelt);
(gdb) list
1307for (rti = *rt; rti->base != NULL; rti++)
1308 memset (rti->base, 0, rti->stride * rti->nelt);
1309
1310 for (rt = gt_ggc_rtab; *rt; rt++)
1311for (rti = *rt; rti->base != NULL; rti++)
1312 memset (rti->base, 0, rti->stride * rti->nelt);
1313
1314 for (rt = gt_pch_scalar_rtab; *rt; rt++)
1315for (rti = *rt; rti->base != NULL; rti++)
1316 memset (rti->base, 0, rti->stride * rti->nelt);
=== What ggc are we destroying?
(gdb) p *rt
$3 = (const ggc_root_tab * const) 0x448e320
(gdb) p rti - *rt
$4 = 5
Fifth element of gt_ggc_r_gt_cp_tree_h:
>From prev-gcc/gt-cp-tree.h:
/* Structures for the easy way to mark roots.
In an array, terminated by having base == NULL. */
struct ggc_root_tab {
void *base;
size_t nelt;
size_t stride;
gt_pointer_walker cb;
gt_pointer_walker pchw;
};
EXPORTED_CONST struct ggc_root_tab gt_ggc_r_gt_cp_tree_h[] = {
...
{ // 4
_op_info[0][0].identifier,
1 * (2) * (OVL_OP_MAX),
sizeof (ovl_op_info[0][0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
{ // 5
_op_info[0][0].name,
1 * (2) * (OVL_OP_MAX),
sizeof (ovl_op_info[0][0]),
(gt_pointer_walker) _ggc_m_S,
(gt_pointer_walker) _pch_n_S
},
{ //6
_op_info[0][0].mangled_name,
1 * (2) * (OVL_OP_MAX),
sizeof (ovl_op_info[0][0]),
(gt_pointer_walker) _ggc_m_S,
[Bug rtl-optimization/111619] 'make profiledbootstrap' makes 10+ minutes on insn-recog.cc (x86_64-linux)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619 Sergei Trofimovich changed: What|Removed |Added Summary|[14 regression] 'make |'make profiledbootstrap' |profiledbootstrap' makes|makes 10+ minutes on |10+ minutes on |insn-recog.cc |insn-recog.cc |(x86_64-linux) |(x86_64-linux) | --- Comment #11 from Sergei Trofimovich --- Tried releases/gcc-12 branch and it's twice as bad: 20 minutes. Removing `Regression` from the subject. $ time /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -gtoggle -fprofile-generate -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/home/slyfox/dev/git/gcc/gcc -I/home/slyfox/dev/git/gcc/gcc/. -I/home/slyfox/dev/git/gcc/gcc/../include -I/home/slyfox/dev/git/gcc/gcc/../libcpp/include -I/home/slyfox/dev/git/gcc/gcc/../libcody -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libbacktrace -o insn-recog.o -MT insn-recog.o -MMD -MP -MF ./.deps/insn-recog.TPo insn-recog.cc real21m24,065s user21m21,966s sys 0m1,135s
[Bug rtl-optimization/111619] [14 regression] 'make profiledbootstrap' makes 10+ minutes on insn-recog.cc (x86_64-linux)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619 --- Comment #8 from Sergei Trofimovich --- Looks like it's mainly -O0. Why not try to use at least -O1 for bootstrap? Perhaps it was a safe default to workaround host compiler bugs in C days. But nowadays gcc uses -std=c++11 with quite a bit of abstractions to remove at -O0. Maybe having a disableable -O1 (or even default -O2) would be a better default?
[Bug rtl-optimization/111619] [14 regression] 'make profiledbootstrap' makes 10+ minutes on insn-recog.cc (x86_64-linux)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619 --- Comment #6 from Sergei Trofimovich --- And here is fomr completeness default checking with CC='gcc -g -O2' CXX='g++ -g -O2': $ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ 'CC=gcc -g -O2' 'CXX=g++ -g -O2' $ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -v Reading specs from /tmp/gb/./prev-gcc/specs COLLECT_GCC=/tmp/gb/./prev-gcc/xg++ COLLECT_LTO_WRAPPER=/tmp/gb/./prev-gcc/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ CC='gcc -g -O2' CXX='g++ -g -O2' Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20230926 (experimental) (GCC) Result is 1m57s: $ time /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -gtoggle -fprofile-generate -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -fno-PIE -I. -I. -I/home/slyfox/dev/git/gcc/gcc -I/home/slyfox/dev/git/gcc/gcc/. -I/home/slyfox/dev/git/gcc/gcc/../include -I/home/slyfox/dev/git/gcc/gcc/../libcpp/include -I/home/slyfox/dev/git/gcc/gcc/../libcody -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libbacktrace -o insn-recog.o -MT insn-recog.o -MMD -MP -MF ./.deps/insn-recog.TPo insn-recog.cc real1m57,549s user1m56,617s sys 0m0,780s
[Bug rtl-optimization/111619] [14 regression] 'make profiledbootstrap' makes 10+ minutes on insn-recog.cc (x86_64-linux)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619 --- Comment #5 from Sergei Trofimovich --- (In reply to Andrew Pinski from comment #3) > Note prev-gcc/cc1plus is compiled at -O0 also which definitely makes things > worse here. Also tried with: '--enable-checking=release -O2 -g' as: $ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ --enable-checking=release 'CC=gcc -g -O2' 'CXX=g++ -g -O2' $ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -v Reading specs from /tmp/gb/./prev-gcc/specs COLLECT_GCC=/tmp/gb/./prev-gcc/xg++ COLLECT_LTO_WRAPPER=/tmp/gb/./prev-gcc/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ --enable-checking=release CC='gcc -g -O2' CXX='g++ -g -O2' Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20230926 (experimental) (GCC) Result is a lot better: 1m55s: $ time /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -gtoggle -fprofile-generate -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -fno-PIE -I. -I. -I/home/slyfox/dev/git/gcc/gcc -I/home/slyfox/dev/git/gcc/gcc/. -I/home/slyfox/dev/git/gcc/gcc/../include -I/home/slyfox/dev/git/gcc/gcc/../libcpp/include -I/home/slyfox/dev/git/gcc/gcc/../libcody -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libbacktrace -o insn-recog.o -MT insn-recog.o -MMD -MP -MF ./.deps/insn-recog.TPo insn-recog.cc real1m55,334s user1m54,146s sys 0m0,993s
[Bug rtl-optimization/111619] [14 regression] 'make profiledbootstrap' makes 10+ minutes on insn-recog.cc (x86_64-linux)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619 --- Comment #4 from Sergei Trofimovich --- (In reply to Andrew Pinski from comment #2) > Can you also try with --enable-checking=release to double check that it is > not the extra compile time checks which is causing issues ... Added --enable-checking=release: $ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -v Reading specs from /tmp/gb/./prev-gcc/specs COLLECT_GCC=/tmp/gb/./prev-gcc/xg++ COLLECT_LTO_WRAPPER=/tmp/gb/./prev-gcc/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ --enable-checking=release Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20230926 (experimental) (GCC) Result did not change much: $ time /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -gtoggle -fprofile-generate -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -fno-PIE -I. -I. -I/home/slyfox/dev/git/gcc/gcc -I/home/slyfox/dev/git/gcc/gcc/. -I/home/slyfox/dev/git/gcc/gcc/../include -I/home/slyfox/dev/git/gcc/gcc/../libcpp/include -I/home/slyfox/dev/git/gcc/gcc/../libcody -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libbacktrace -o insn-recog.o -MT insn-recog.o -MMD -MP -MF ./.deps/insn-recog.TPo insn-recog.cc real12m18,994s user12m17,085s sys 0m1,001s
[Bug target/111619] [14 regression] 'make profiledbootstrap' makes 10+ minutes on insn-recog.cc (x86_64-linux)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619 --- Comment #1 from Sergei Trofimovich --- -ftime-report breakdown: time /tmp/gb/./prev-gcc/cc1plus -quiet -nostdinc++ -I /tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I /tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I /home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -I . -I . -I /home/slyfox/dev/git/gcc/gcc -I /home/slyfox/dev/git/gcc/gcc/. -I /home/slyfox/dev/git/gcc/gcc/../include -I /home/slyfox/dev/git/gcc/gcc/../libcpp/include -I /home/slyfox/dev/git/gcc/gcc/../libcody -I /home/slyfox/dev/git/gcc/gcc/../libdecnumber -I /home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I ../libdecnumber -I /home/slyfox/dev/git/gcc/gcc/../libbacktrace -iprefix /tmp/gb/prev-gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/ -isystem /tmp/gb/./prev-gcc/include -isystem /tmp/gb/./prev-gcc/include-fixed -MMD insn-recog.d -MF ./.deps/insn-recog.TPo -MP -MT insn-recog.o -D_GNU_SOURCE -D IN_GCC -D HAVE_CONFIG_H insn-recog.cc -quiet -dumpbase insn-recog.cc -dumpbase-ext .cc -mtune=generic -march=x86-64 -g -gtoggle -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wsuggest-attribute=format -Wconditionally-supported -Woverloaded-virtual=2 -Wpedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-checking -fprofile-generate -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common -fno-PIE -o /run/user/1000/ccQK54tL.s -ftime-report Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 1892k ( 0%) phase parsing : 22.49 ( 3%) 1.58 ( 35%) 24.09 ( 3%) 903M ( 22%) phase lang. deferred : 0.06 ( 0%) 0.01 ( 0%) 0.07 ( 0%) 2268k ( 0%) phase opt and generate : 791.23 ( 97%) 2.90 ( 65%) 794.84 ( 97%) 3111M ( 77%) |name lookup : 1.20 ( 0%) 0.09 ( 2%) 1.23 ( 0%) 3296k ( 0%) |overload resolution : 3.40 ( 0%) 0.18 ( 4%) 3.69 ( 0%) 107M ( 3%) garbage collection : 5.82 ( 1%) 0.08 ( 2%) 5.86 ( 1%) 0 ( 0%) dump files : 0.24 ( 0%) 0.00 ( 0%) 0.15 ( 0%) 0 ( 0%) callgraph construction : 4.41 ( 1%) 0.14 ( 3%) 4.74 ( 1%) 329M ( 8%) callgraph optimization : 1.01 ( 0%) 0.03 ( 1%) 1.02 ( 0%) 2938k ( 0%) callgraph functions expansion : 734.71 ( 90%) 2.08 ( 46%) 737.44 ( 90%) 2238M ( 56%) callgraph ipa passes : 50.35 ( 6%) 0.71 ( 16%) 51.10 ( 6%) 437M ( 11%) ipa function summary : 1.89 ( 0%) 0.00 ( 0%) 1.90 ( 0%) 5969k ( 0%) ipa dead code removal : 0.22 ( 0%) 0.00 ( 0%) 0.22 ( 0%) 0 ( 0%) ipa devirtualization : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 ( 0%) ipa cp : 0.55 ( 0%) 0.00 ( 0%) 0.56 ( 0%) 3831k ( 0%) ipa inlining heuristics: 0.57 ( 0%) 0.03 ( 1%) 0.46 ( 0%) 20M ( 1%) ipa comdats: 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) ipa reference : 0.03 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 0 ( 0%) ipa profile: 5.98 ( 1%) 0.07 ( 2%) 6.11 ( 1%) 108M ( 3%) ipa pure const : 0.57 ( 0%) 0.01 ( 0%) 0.55 ( 0%) 1080 ( 0%) ipa icf: 1.37 ( 0%) 0.00 ( 0%) 1.37 ( 0%) 45k ( 0%) ipa SRA: 4.22 ( 1%) 0.01 ( 0%) 4.27 ( 1%) 6213k ( 0%) ipa free lang data : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 ( 0%) ipa free inline summary: 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) ipa modref : 1.33 ( 0%) 0.00 ( 0%) 1.33 ( 0%) 1893k ( 0%) cfg construction : 0.19 ( 0%) 0.00 ( 0%) 0.13 ( 0%) 12M ( 0%) cfg cleanup: 3.35 ( 0%) 0.00 ( 0%) 3.71 ( 0%) 9974k ( 0%) trivially dead code: 0.90 ( 0%) 0.01 ( 0%) 0.77 ( 0%) 0 ( 0%) df scan insns : 1.45 ( 0%) 0.00 ( 0%) 1.39 ( 0%) 95k ( 0%) df reaching defs : 1.79 ( 0%) 0.00 ( 0%) 1.83 ( 0%) 0 ( 0%) df live regs : 6.03 ( 1%) 0.01 ( 0%) 5.78 ( 1%) 0 ( 0%) df live regs : 2.55 ( 0%) 0.00 ( 0%) 2.49 ( 0%) 0 ( 0%) df must-initialized regs : 0.19 ( 0%) 0.00 ( 0%) 0.20 ( 0%) 0 ( 0%) df use-def / def-use chains: 1.13 ( 0%) 0.00 ( 0%) 1.05 ( 0%) 0 ( 0%) df reg dead/unused notes : 2.89 ( 0%) 0.01 ( 0%) 2.79 ( 0%) 34M ( 1%) register information : 0.45 ( 0%) 0.00 ( 0%)
[Bug target/111619] New: [14 regression] 'make profiledbootstrap' makes 10+ minutes on insn-recog.cc (x86_64-linux)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619 Bug ID: 111619 Summary: [14 regression] 'make profiledbootstrap' makes 10+ minutes on insn-recog.cc (x86_64-linux) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- The reproducer on gcc from r14-4300-g1fab05a885a308: $ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ $ make profiledbootstrap insn-recog.o takes ~13 min to build on `AMD Ryzen 9 5950X` CPU: $ time /tmp/gb/./prev-gcc/cc1plus -quiet -nostdinc++ -I /tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I /tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I /home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -I . -I . -I /home/slyfox/dev/git/gcc/gcc -I /home/slyfox/dev/git/gcc/gcc/. -I /home/slyfox/dev/git/gcc/gcc/../include -I /home/slyfox/dev/git/gcc/gcc/../libcpp/include -I /home/slyfox/dev/git/gcc/gcc/../libcody -I /home/slyfox/dev/git/gcc/gcc/../libdecnumber -I /home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I ../libdecnumber -I /home/slyfox/dev/git/gcc/gcc/../libbacktrace -iprefix /tmp/gb/prev-gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/ -isystem /tmp/gb/./prev-gcc/include -isystem /tmp/gb/./prev-gcc/include-fixed -MMD insn-recog.d -MF ./.deps/insn-recog.TPo -MP -MT insn-recog.o -D_GNU_SOURCE -D IN_GCC -D HAVE_CONFIG_H insn-recog.cc -quiet -dumpbase insn-recog.cc -dumpbase-ext .cc -mtune=generic -march=x86-64 -g -gtoggle -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wsuggest-attribute=format -Wconditionally-supported -Woverloaded-virtual=2 -Wpedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-checking -fprofile-generate -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common -fno-PIE -o /run/user/1000/ccQK54tL.s real13m39,864s user13m38,263s sys 0m0,823s `insn-recog.cc` is 8.3MB. $ ./prev-gcc/xgcc -Bprev-gcc -v Reading specs from prev-gcc/specs COLLECT_GCC=./prev-gcc/xgcc COLLECT_LTO_WRAPPER=prev-gcc/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20230926 (experimental) (GCC)
[Bug ipa/111283] [14 Regression] gnat profilebootstrap broken on trunk 20230902 on 32bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283 --- Comment #9 from Sergei Trofimovich --- Proposed conservative fix as https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631526.html
[Bug gcov-profile/111559] [14 regression] ICE when building Python with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559 --- Comment #7 from Sergei Trofimovich --- Proposed conservative fix as https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631526.html
[Bug gcov-profile/111559] [14 regression] ICE when building Python with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559
--- Comment #6 from Sergei Trofimovich ---
Uninitialized value comes from `ipa_merge_profiles()` for our `rule1_same()`
alias and `rule1()` functions:
// in gcc/ipa-icf.cc:
else if (create_alias)
{
alias->icf_merged = true;
/* Remove the function's body. */
ipa_merge_profiles (original, alias);
// ...
If I comment out `ipa_merge_profiles (original, alias);` call to leave
`original` as is then failure does not happen. Which means at least
`original`'s profile is fine.
Tracing through `ipa_merge_profiles()` we generate uninitialized probalility
profile when divide by zero at:
// in gcc/ipa-utils.cc
void
ipa_merge_profiles (struct cgraph_node *dst,
struct cgraph_node *src,
bool preserve_body)
// ...
/* TODO: merge also statement histograms. */
FOR_ALL_BB_FN (srcbb, srccfun)
{
unsigned int i;
if (copy_counts) { /* snip: ireelevant */ }
else
{
for (i = 0; i < EDGE_COUNT (srcbb->succs); i++)
{
edge srce = EDGE_SUCC (srcbb, i);
edge dste = EDGE_SUCC (dstbb, i);
dste->probability =
dste->probability * dstbb->count.ipa ().probability_in
(dstbb->count.ipa ()
+ srccount.ipa ())
+ srce->probability * srcbb->count.ipa ().probability_in
(dstbb->count.ipa ()
+ srccount.ipa ());
}
dstbb->count = dstbb->count.ipa () + srccount.ipa ();
}
}
// ...
Here `dstbb->count.ipa () + srccount.ipa ()` is zero.
This assert should expose it as well:
--- a/gcc/ipa-utils.cc
+++ b/gcc/ipa-utils.cc
@@ -651,13 +651,15 @@ ipa_merge_profiles (struct cgraph_node *dst,
{
edge srce = EDGE_SUCC (srcbb, i);
edge dste = EDGE_SUCC (dstbb, i);
+
+ profile_count den = dstbb->count.ipa () + srccount.ipa ();
+ gcc_assert(den.nonzero_p());
+
dste->probability =
dste->probability * dstbb->count.ipa ().probability_in
-(dstbb->count.ipa ()
- + srccount.ipa ())
+(den)
+ srce->probability * srcbb->count.ipa ().probability_in
-(dstbb->count.ipa ()
- + srccount.ipa ());
+(den);
}
dstbb->count = dstbb->count.ipa () + srccount.ipa ();
}
If we attach `gdb` it agrees we exercise these edges 0 times.
(gdb) call dstbb->count.debug()
0 (precise)
(gdb) call srccount.ipa ().debug()
0 (precise)
For comparison we are trying to clobber `always` probability with `undefined`:
(gdb) call dste->probability.debug()
always
What edge is that?
(gdb) call debug_edge(srce)
edge (bb_3, bb_4)
__attribute__((noinline))
void rule1 ()
{
int p.0_1;
[count: 2]:
p.0_1 = p;
if (p.0_1 != 0)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
edge ();
[count: 2]:
return;
}
`always` should valid for `bb_3->bb_4`. But for our data input it's `never`.
[Bug gcov-profile/111559] [14 regression] ICE when building Python with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559
--- Comment #5 from Sergei Trofimovich ---
Slightly shorter example that does not rely on inline:
// $ cat bug.c
__attribute__((noipa)) static void edge(void) {}
int p = 0;
__attribute__((noinline))
static void rule1(void) { if (p) edge(); }
__attribute__((noinline))
static void rule1_same(void) { if (p) edge(); }
__attribute__((noipa)) int main(void) {
rule1();
rule1_same();
}
bug.c: In function 'rule1':
bug.c:6:13: error: probability of edge 3->4 not initialized
6 | static void rule1(void) { if (p) edge(); }
| ^
during GIMPLE pass: fixup_cfg
bug.c:6:13: internal compiler error: verify_flow_info failed
[Bug gcov-profile/111559] [14 regression] ICE when building Python with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559
--- Comment #4 from Sergei Trofimovich ---
Looks like identical code folding creates uninitialized profile counters if
there are any edges in folded functions.
I think cvise did a decent job extracting the reproducer below. Here is a
single-file trigger on `--enable-checking=yes` `gcc` from `master`:
```
// $ cat bug.c
__attribute__((noipa)) static void edge(void) {}
static void rule1(int *p) {
edge();
if (*p) edge();
}
static void rule1_same(int *p) {
edge();
if (*p) edge();
}
__attribute__((noipa)) int main(void) {
int p = 0;
rule1();
rule1_same();
}
```
Trigger:
```
$ echo PG
$ gcc -O2 -fprofile-generate bug.c -o b -fopt-info
$ echo RUN
$ ./b
$ echo PU
$ gcc -O2 -fprofile-use -fprofile-correction bug.c -o b -fopt-info
```
Running:
```
PG
$ gcc -O2 -fprofile-generate bug.c -o b -fopt-info
bug.c:15:5: optimized: Inlined rule1.constprop/28 into main/3 which now has
time 75.28 and size 51, net change of -6.
bug.c:16:5: optimized: Inlined rule1_same.constprop/27 into main/3 which now
has time 94.56 and size 72, net change of -6.
RUN
$ ./b
PU
$ gcc -O2 -fprofile-use -fprofile-correction bug.c -o b -fopt-info
bug.c:3:13: optimized: Semantic equality hit:rule1/1->rule1_same/2
bug.c:3:13: optimized: Assembler symbol names:rule1/1->rule1_same/2
bug.c:15:5: optimized: Inlined rule1.constprop/5 into main/3 which now has
time 26.00 and size 10, net change of +2.
bug.c:16:5: optimized: Inlined rule1.constprop/4 into main/3 which now has
time 27.00 and size 12, net change of -6.
bug.c: In function 'main':
bug.c:13:28: error: probability of edge 3->4 not initialized
13 | __attribute__((noipa)) int main(void) {
|^~~~
bug.c:13:28: error: probability of edge 5->6 not initialized
during IPA pass: inline
bug.c:13:28: internal compiler error: verify_flow_info failed
```
[Bug gcov-profile/111559] [14 regression] ICE when building Python with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #2 from Sergei Trofimovich --- Possibly exposed by r14-3459-g0c78240fd7d519 "Check that passes do not forget to define profile"
[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527 --- Comment #2 from Sergei Trofimovich --- (In reply to Richard Biener from comment #1) > Hm, but the COLLECT_GCC_OPTIONS variable is only used for communicating > between the driver and the linker, the options therein are individually > passed to the program execved? AFAIU the driver sets `COLLECT_GCC_OPTIONS` variable and never unsets it. As a result it affects all the `exevce() calls. Be it `cc1`, `as` or anything else regardless of the fact if it uses the variable or not. `cc1` is probably the first casualty. As a simplistic example here we break `ls` with too large environment file: $ COLLECT_GCC_OPTIONS=$(printf "%0*d" 20 0) ls -bash: /run/current-system/sw/bin/ls: Argument list too long > You are maybe looking for the -f*-map options to take a file as input > containing multiple mappings? `NixOS` is also occasionally hottong the same limit by passing too many include an library paths: -I/nix/store/hash1-foo/include -I/nix/store/hash2-bar/include ... -L/nix/store/hash1-foo/lib -L/nix/store/hash2-bar/lib ... -Wl,-rpath,/nix/store/hash1-foo/lib -Wl,-rpath,/nix/store/hash2-bar/lib I wonder if we could solve all of these limitations here by at least avoiding `COLLECT_GCC_OPTIONS`. But otherwise if generic fix is too invasive change then passing a mapping file should do as well. What would be an acceptable for of the file? A new option, like? -fmacro-prefix-map-file=./foo with entries of exactly the same form $ cat foo /nix/store/hash1-foo=/nix/store/-foo /nix/store/hash2-bar=/nix/store/-bar ... Or maybe reuse existing -fmacro-prefix-map= and use response-style file input? Like -fmacro-prefix-map=@./foo. clang would probably need the same handling if we were to extend the driver.
[Bug driver/111527] New: COLLECT_GCC_OPTIONS option hits single-variable limits too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527 Bug ID: 111527 Summary: COLLECT_GCC_OPTIONS option hits single-variable limits too early Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Tl;DR: linux allows you to pass up to 2MB of command line arguments to the tools limiting each individual option to 128KB. Unfortunately `gcc` collects all the options into a single `COLLECT_GCC_OPTIONS` variable and hits the smaller 128KB limit. This causes periodic problems for distributions that install each individual package into a separate directory. One of them is `NixOS`. Could `gcc` be amended not to use single limiting `COLLECT_GCC_OPTIONS` variable and use, say, direct arguments to pass options around? Or even use response file if it hits `-E2BIG`? Fake reproducer: 2 huge variables that programs normally accept, but not `gcc`: $ big_100k_var=$(printf "%0*d" 10 0) # this works: 200KB of options for `printf` external command $ $(which printf) "%s %s" $big_100k_var $big_100k_var >/dev/null; echo $? 0 # this fails: 200KB of options for `gcc`, fails in `cc1` $ touch a.c; gcc -c a.c -DA=$big_100k_var -DB=$big_100k_var gcc: fatal error: cannot execute 'cc1': execv: Argument list too long compilation terminated. Thanks! MOre words In `nixpkgs` repository each package gets installed into it's own unique directory: /nix/store/hash1-foo/include/foo.h /nix/store/hash2-bar/include/bar.h ... If any of those encounter `__FILE__` macros in static inline functions they usually embed full path to header files into final binaries as is. I wanted to remap all those paths into form that does not contain hashes: -fmacro-prefix-map=/nix/store/hash1-foo/include/foo.h=/nix/store/-foo/include/foo.h -fmacro-prefix-map=/nix/store/hash2-bar/include/bar.h=/nix/store/-bar/include/bar.h ... When I got to packages that use about ~100 include directories I started getting errors from `cc1`: ``` Command line: `gcc -m64 -mcx16 $remap_options /build/qemu-8.1.0/build/meson-private/tmpbyikv8nc/testfile.c \ -o /build/qemu-8.1.0/build/meson-private/tmpbyikv8nc/output.exe -D_FILE_OFFSET_BITS=64 \ -O0 -Wl,--start-group -laio -Wl,--end-group -Wl,--allow-shlib-undefined` -> 1 stderr: gcc: fatal error: cannot execute 'cc1': execv: Argument list too long compilation terminated. ``` The limit felt too low and I found the `COLLECT_GCC_OPTIONS` variable.
[Bug tree-optimization/111435] [14 Regression] gimple_zero_one_valued_p() infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435 --- Comment #10 from Sergei Trofimovich --- The proposed patch fixes my modified i686-linux gcc bootstrap as well. Thank you!
[Bug tree-optimization/111435] [14 Regression] gimple_zero_one_valued_p() infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435
--- Comment #4 from Sergei Trofimovich ---
Meanwhile cvise extracted this test:
// $ cat tree-ssa-loop-niter.cc.cc
int discover_iteration_bound_by_body_walk_queue_index, m_vec;
int *address();
unsigned length();
int deref(unsigned ix) {
int __trans_tmp_1 = address()[ix];
return __trans_tmp_1;
}
unsigned discover_iteration_bound_by_body_walk___trans_tmp_4;
void discover_iteration_bound_by_body_walk() {
bool __trans_tmp_3 = m_vec;
if (!__trans_tmp_3)
return;
discover_iteration_bound_by_body_walk___trans_tmp_4 = m_vec ? length() : 0;
discover_iteration_bound_by_body_walk_queue_index =
discover_iteration_bound_by_body_walk___trans_tmp_4;
for (;;)
deref(discover_iteration_bound_by_body_walk_queue_index);
}
[Bug tree-optimization/111435] New: [14 Regression] gimple_zero_one_valued_p() infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435 Bug ID: 111435 Summary: [14 Regression] gimple_zero_one_valued_p() infinite recursion Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Created attachment 55911 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55911=edit tree-ssa-loop-niter.cc.cc.gz Noticed on i686-linux gcc bootstrap when building r14-4077-g86451305d8b2a2. Reproduced on x86_64-linux -m32 as well. r14-4038-gb975c0dc3be285 looks suspicious. The reduction is a bit slow. Attaching partially reduced. How to crash: $ gcc/xg++ -Bgcc ~/dev/bugs/gcc-14-i686-ICE/tree-ssa-loop-niter.cc.cc -O2 -m32 --verbose Or: $ gcc/cc1plus -quiet -imultilib . -iprefix /tmp/gb/gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/ -isystem gcc/include -isystem gcc/include-fixed -D_GNU_SOURCE /home/slyfox/dev/bugs/gcc-14-i686-ICE/tree-ssa-loop-niter.cc.cc -quiet -dumpdir a- -dumpbase tree-ssa-loop-niter.cc.cc -dumpbase-ext .cc -m32 -mtune=generic -march=x86-64 -O2 -version -o /run/user/1000/ccgZ63HD.s GNU C++17 (GCC) version 14.0.0 20230916 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 14.0.0 20230916 (experimental), GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 7c2c55b6bcbe18476b6d2c66d34ac4cc Segmentation fault (core dumped) Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0150a239 in get_nonzero_bits (name=0x7fffe8c02240) at /home/slyfox/dev/git/gcc/gcc/tree-ssanames.cc:494 494 unsigned int precision = element_precision (TREE_TYPE (name)); (gdb) bt #0 0x0150a239 in get_nonzero_bits (name=0x7fffe8c02240) at /home/slyfox/dev/git/gcc/gcc/tree-ssanames.cc:494 #1 0x0150ad4c in get_nonzero_bits (name=) at /home/slyfox/dev/git/gcc/gcc/tree-ssanames.cc:489 #2 0x00f04105 in tree_nonzero_bits (t=t@entry=0x7fffe8c02240) at /home/slyfox/dev/git/gcc/gcc/fold-const.cc:16792 #3 0x021de3ce in gimple_zero_one_valued_p (t=0x7fffe8c02240, valueize=valueize@entry=0x14a18c0 ) at gimple-match-3.cc:19 #4 0x021de537 in gimple_zero_one_valued_p (t=0x7fffe8c02090, valueize=valueize@entry=0x14a18c0 ) at gimple-match-3.cc:70 #5 0x021de537 in gimple_zero_one_valued_p (t=0x7fffe8c02240, valueize=valueize@entry=0x14a18c0 ) at gimple-match-3.cc:70 #6 0x021de537 in gimple_zero_one_valued_p (t=0x7fffe8c02090, valueize=valueize@entry=0x14a18c0 ) at gimple-match-3.cc:70 ...
[Bug target/111051] [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline' '__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111051 Sergei Trofimovich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Sergei Trofimovich --- Sounds reasonable. Closing as FIXED.
[Bug tree-optimization/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above since r14-3243-ga7dba4a1c05a76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111048 --- Comment #11 from Sergei Trofimovich --- I confirm highway-1.0.6 still passes the tests with Prathamesh's fix. Thank you!
[Bug target/111060] [14 Regression] i686-linux bootstrap failure: i686-unknown-linux-gnu/libstdc++-v3/include/limits:1986:1: error: SSE register return with SSE2 disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111060 --- Comment #3 from Sergei Trofimovich --- The patch fixed gcc buid on i686-linux for me. Thank you!
[Bug target/111060] New: [14 Regression] i686-linux bootstrap failure: i686-unknown-linux-gnu/libstdc++-v3/include/limits:1986:1: error: SSE register return with SSE2 disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111060 Bug ID: 111060 Summary: [14 Regression] i686-linux bootstrap failure: i686-unknown-linux-gnu/libstdc++-v3/include/limits:198 6:1: error: SSE register return with SSE2 disabled Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Noticed bootstrap failure on r14-3320-g7f8d730a563983 today: $ ~/dev/git/gcc/configure --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu --target=i686-unknown-linux-gnu && make ... /tmp/gb/./gcc/xgcc -shared-libgcc -B/tmp/gb/./gcc -nostdinc++ -L/tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/src -L/tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/i686-unknown-linux-gnu/bin/ -B/usr/local/i686-unknown-linux-gnu/lib/ -isystem /usr/local/i686-unknown-linux-gnu/include -isystem /usr/local/i686-unknown-linux-gnu/sys-include -fno-checking -x c++-header -nostdinc++ -g -O2 -D_GNU_SOURCE -I/tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/include/i686-unknown-linux-gnu -I/tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/include -I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /home/slyfox/dev/git/gcc/libstdc++-v3/include/precompiled/stdc++.h \ -o i686-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /home/slyfox/dev/git/gcc/libstdc++-v3/include/precompiled/stdc++.h:55: /tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/include/limits: In static member function 'static constexpr _Float16 std::numeric_limits<_Float16>::min()': /tmp/gb/i686-unknown-linux-gnu/libstdc++-v3/include/limits:1986:1: error: SSE register return with SSE2 disabled
[Bug target/111051] [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline' '__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111051 --- Comment #5 from Sergei Trofimovich --- The change fixed highway-1.0.6 build for me. Thank you!
[Bug target/111051] [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline' '__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111051
--- Comment #1 from Sergei Trofimovich ---
Found this difference, looks reasonable?
// $ cat a.cc
#include
#pragma GCC target("avx512vl,avx512dq")
void bug(__m256i i) {
volatile auto v1 = _mm256_cvtepi64_pd(i);
}
Difference:
$ g++-13 -c a.cc
# ok
$ g++-14 -c a.cc
In file included from
/<>/gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/immintrin.h:71,
from a.cc:1:
/<>/gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avx512vldqintrin.h:
In function '__m256d _mm256_cvtepi64_pd(__m256i)':
/<>/gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avx512vldqintrin.h:910:1:
note: the ABI for passing parameters with 32-byte alignment has changed in GCC
4.6
910 | _mm256_cvtepi64_pd (__m256i __A)
| ^~
a.cc:7:1: warning: AVX vector return without AVX enabled changes the ABI
[-Wpsabi]
7 | }
| ^
In file included from
/<>/gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/immintrin.h:43:
/<>/gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1:
error: inlining failed in call to 'always_inline' '__m256d
_mm256_setzero_pd()': target specific option mismatch
1238 | _mm256_setzero_pd (void)
| ^
/<>/gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avx512vldqintrin.h:912:10:
note: called from here
912 | return (__m256d) __builtin_ia32_cvtqq2pd256_mask ((__v4di) __A,
| ^~~~
913 | (__v4df)
|
914 | _mm256_setzero_pd
(),
|
~
915 | (__mmask8) -1);
| ~~
[Bug target/111051] New: [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111051
Bug ID: 111051
Summary: [14 Regression] highway-1.0.6 fails to build as
gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/inc
lude/avxintrin.h:1238:1: error: inlining failed in
call to 'always_inline' '__m256d _mm256_setzero_pd()':
target specific option mismatch
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Observed build failure on today's gcc from r14-3296-gdc48d1d1d44587 against
highway-1.0.6 ( https://github.com/google/highway ).
I have not managed to extract nice example ot of it yet, but maybe it's obvious
to you?
The (somewhat big) reproducer is:
$ git clone https://github.com/google/highway
$ cd highway
$ mkdir b
$ cd b
$ cmake .. -DCMAKE_BUILD_TYPE=Release
$ make
...
LANG=C /nix/store/vmrxs83fhqs6d3gsyg97hh0lbfzhk9jl-gcc-wrapper-14.0.0/bin/g++
-DHWY_STATIC_DEFINE -DTOOLCHAIN_MISS_ASM_HWCAP_H -I/home/slyfox/dev/git/highway
-isystem /home/slyfox/dev/git/highway/b/googletest-src/googletest/include
-isystem /home/slyfox/dev/git/highway/b/googletest-src/googletest -O3 -DNDEBUG
-fPIE -fvisibility=hidden -fvisibility-inlines-hidden
-Wno-builtin-macro-redefined -D__DATE__=\"redacted\"
-D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants
-Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor
-fmath-errno -fno-exceptions -DHWY_IS_TEST=1 -MD -MT
CMakeFiles/math_test.dir/hwy/contrib/math/math_test.cc.o -MF
CMakeFiles/math_test.dir/hwy/contrib/math/math_test.cc.o.d -o
CMakeFiles/math_test.dir/hwy/contrib/math/math_test.cc.o -c
/home/slyfox/dev/git/highway/hwy/contrib/math/math_test.cc
In file included from
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/immintrin.h:71,
from /home/slyfox/dev/git/highway/hwy/ops/x86_256-inl.h:36,
from /home/slyfox/dev/git/highway/hwy/highway.h:407,
from
/home/slyfox/dev/git/highway/hwy/contrib/math/math_test.cc:25,
from /home/slyfox/dev/git/highway/hwy/foreach_target.h:94,
from
/home/slyfox/dev/git/highway/hwy/contrib/math/math_test.cc:24:
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avx512vldqintrin.h:
In function '__m256 _mm256_mask_xor_ps(__m256, __mmask8, __m256, __m256)':
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avx512vldqintrin.h:1154:1:
note: the ABI for passing parameters with 32-byte alignment has changed in GCC
4.6
1154 | _mm256_mask_xor_ps (__m256 __W, __mmask8 __U, __m256 __A, __m256 __B)
| ^~
/home/slyfox/dev/git/highway/hwy/contrib/math/math_test.cc:439:1: warning: AVX
vector return without AVX enabled changes the ABI [-Wpsabi]
439 | } // namespace hwy
| ^
In file included from
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/immintrin.h:43:
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:
In function '__m256d _mm256_cvtepi64_pd(__m256i)':
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1:
error: inlining failed in call to 'always_inline' '__m256d
_mm256_setzero_pd()': target specific option mismatch
1238 | _mm256_setzero_pd (void)
| ^
/nix/store/9j5pznccwi0vzmj91w8yr2kiwdm37c5p-gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avx512vldqintrin.h:912:10:
note: called from here
912 | return (__m256d) __builtin_ia32_cvtqq2pd256_mask ((__v4di) __A,
| ^~~~
913 | (__v4df)
|
914 | _mm256_setzero_pd
(),
|
~
915 | (__mmask8) -1);
| ~~
I have a suspiction it's related to AVX10 changes, like
r14-3268-g0b20e0f17b47a8 which remove `#pragma GCC
target("avx512vl,avx512dq")`. Probably not that one specifically though.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix
[Bug middle-end/111009] [12/13/14 regression] -fno-strict-overflow erroneously elides null pointer checks and causes SIGSEGV on perf from linux-6.4.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009 --- Comment #12 from Sergei Trofimovich --- I confirm the change fixed `perf` startup for me. Thank you!
[Bug target/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111048 Sergei Trofimovich changed: What|Removed |Added CC||richard.sandiford at arm dot com --- Comment #1 from Sergei Trofimovich --- `git bisect` points at r14-3243-ga7dba4a1c05a76: commit a7dba4a1c05a76026d88d0b519cf83bff9a2 Date: Wed Aug 16 16:51:44 2023 +0530 Extend fold_vec_perm to handle VLA vector_cst.
[Bug target/111048] New: [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111048
Bug ID: 111048
Summary: [14 Regression] Wrong AVX2 code on highway-1.0.6 on
-O2 and above
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Noticed wrong code with r14-3259-g24f7b20bbd87eb when running tests on
highway-1.0.6. Extracted example:
// $ cat bug.cc.cc
typedef unsigned char u8;
__attribute__((noipa))
static void check(const u8 * v) {
if (*v != 15) __builtin_trap();
}
__attribute__((noipa))
static void bug(void) {
u8 in_lanes[32];
for (unsigned i = 0; i < 32; i += 2) {
in_lanes[i + 0] = 0;
in_lanes[i + 1] = ((u8)0xff) >> (i & 7);
}
check(_lanes[13]);
}
int main() {
bug();
}
Triggering:
$ g++ bug.cc.cc -mavx2 -O2 -o bug2 && ./bug2
Illegal
$ g++ bug.cc.cc -mavx2 -O1 -o bug1 && ./bug1
$ g++ -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-14.0.0
--with-gmp-include=/<>/gmp-6.3.0-dev/include
--with-gmp-lib=/<>/gmp-6.3.0/lib
--with-mpfr-include=/<>/mpfr-4.2.0-12-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.0-12/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.38-dev/include
--with-build-sysroot=/ --program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --disable-bootstrap
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 (experimental) (GCC)
[Bug middle-end/111009] [12/13/14 regression] -fno-strict-overflow erroneously elides null pointer checks and causes SIGSEGV on perf from linux-6.4.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009 --- Comment #9 from Sergei Trofimovich --- Created attachment 55744 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55744=edit bug.S At the hazard of stating the obvious: it's a wrong-code when you execute it (not a gcc ICE). Should fail on vanilla x86_64-linux-gnu. Tested on today's r14-3254-g9ade70bb86c874 as: $ gcc -Bgcc bug.c.c -fno-strict-overflow -O3 -o bug && ./bug Segmentation fault (core dumped) I also uploaded bug.S as an output of $ gcc -Bgcc bug.c.c -fno-strict-overflow -O3 -S -fverbose-asm -o bug.S if it helps you to find why your output is different.
[Bug middle-end/111009] [12/13/14 regression] -fno-strict-overflow erroneously elides null pointer checks and causes SIGSEGV on perf from linux-6.4.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009 --- Comment #7 from Sergei Trofimovich --- commit bd400db6d3ec167142ace352db00f84d382e33a8 (HEAD) Date: Fri Oct 15 12:06:27 2021 -0400 Add --param=vrp1-mode and --param=vrp2-mode. (the first commit that adds the option) generates SIGSEGVs all the same: $ gcc/xgcc -Bgcc ~/dev/bugs/gcc-14-perf-wrong-code-PR111009/bug.c.c -fno-strict-overflow -O3 -o bug --param=vrp2-mode=ranger && ./bug Segmentation fault (core dumped) Not much to bisect.
