[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The original testcase started to be rejected with r12-4425-g1595fe44e11a969d8ae462212886fb0a87b46226 The second one indeed starting with r8-2720-gf44a8dd56f5bfbd0596c39693e268ef880c06221
[Bug modula2/108259] Modula-2 module constructors symbols in (shared) libraries are hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108259
--- Comment #3 from Iain Sandoe ---
this patch shows the problem - because it removes the shadowing "-L" options.
Obviously, we cannot apply it without creating 'regressions'...
[PATCH] modula-2, driver: Do not add extra '-L' options that shadow
$libdir.
The driver is adding one '-L' option for each path to libm2xxx.a which is
shadowing $libpath where the shared libraries are installed. This prevents
the shared libraries from being found (there are also convenience libs
in $libdir, so the additional -L options are not needed).
gcc/m2/ChangeLog:
* gm2spec.cc (add_default_combination): Do not add extra library
paths for the libm2xxx.a libraries.
---
gcc/m2/gm2spec.cc | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/m2/gm2spec.cc b/gcc/m2/gm2spec.cc
index 3c91479df16..4996fa49789 100644
--- a/gcc/m2/gm2spec.cc
+++ b/gcc/m2/gm2spec.cc
@@ -289,7 +289,6 @@ add_default_combination (const char *libpath, const char
*library)
{
if (library != NULL)
{
- append_option (OPT_L, build_archive_path (libpath, library), 1);
append_option (OPT_l, safe_strdup (library), 1);
return true;
}
--
[Bug ada/108202] [13 Regression] Many new acats fails on 32bit Darwin hosts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108202 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:8385088039f58a1d403cbb0792105236d240de85 commit r13-4952-g8385088039f58a1d403cbb0792105236d240de85 Author: Iain Sandoe Date: Thu Dec 22 17:32:59 2022 + Ada,Darwin: Do not link libgcc statically on Darwin 8 and 9 [PR108202]. Normally, GCC executables are built with -static-libstdc++ -static-libgcc on Darwin. This is fine in most cases, because GCC executables typically do no use exceptions. However gnat1 does use exceptions and also pulls in system libraries that are linked against the installed shared libgcc which contains the system unwinder. This means that gnat1 effectively has two unwinder instances (which does not work reliably since the unwinders have global state). A recent change in the initialization of FDEs has made this a hard error now on Darwin versions (8 and 9) with libgcc installed in /usr/lib (gnat1 now hangs when an exception is thrown). The solution is to link libgcc dynamically, picking up the installed system version. To do this we strip -static-libgcc from the link flags. PR ada/108202 gcc/ada/ChangeLog: * gcc-interface/Make-lang.in (GCC_LINKERFLAGS, GCC_LDFLAGS): Versions of ALL_LINKERFLAGS, LDFLAGS with -Werror and -static-libgcc filtered out for Darwin8 and 9 (-Werror is filtered out for other hosts).
[Bug ada/108202] [13 Regression] Many new acats fails on 32bit Darwin hosts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108202 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Sandoe --- fixed (needs r13-4870/4883 if we ever want to back port it).
[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Iain Sandoe --- fixed.
[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183 Iain Sandoe changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108259, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108261 --- Comment #19 from Iain Sandoe --- the initial part of this is now fixed on trunk, but the follow-on questions/patch and subsidiary issues remain.
[Bug rtl-optimization/108263] New: [13 Regression] ICE building Linux kernel on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108263
Bug ID: 108263
Summary: [13 Regression] ICE building Linux kernel on ppc64le
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
int v, *p;
void
foo (void)
{
int i;
for (i = 0;; i++)
{
if (v)
{
__label__ l1;
asm goto ("" : : : : l1);
l1:
return;
}
if (p[i])
break;
}
asm goto ("" : : "r" (i) : : l2);
l2:
}
ICEs with -O2 on powerpc64le-linux:
kernel-ice.i: In function ‘foo’:
kernel-ice.i:21:1: error: in basic block 9:
21 | }
| ^
kernel-ice.i:21:1: error: flow control insn inside a basic block
(jump_insn 84 3 87 9 (parallel [
(asm_operands/v ("") ("") 0 [
(reg/v:SI 10 10 [orig:120 i ] [120])
]
[
(asm_input:SI ("r") kernel-ice.i:19)
]
[
(label_ref:DI 42)
] kernel-ice.i:19)
(clobber (reg:SI 98 ca))
]) "kernel-ice.i":19:3 -1
(expr_list:REG_DEAD (reg/v:SI 10 10 [orig:120 i ] [120])
(expr_list:REG_UNUSED (reg:SI 98 ca)
(nil)))
-> 42)
during RTL pass: bbro
kernel-ice.i:21:1: internal compiler error: in rtl_verify_bb_insns, at
cfgrtl.cc:2797
[Bug rtl-optimization/108263] [13 Regression] ICE building Linux kernel on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108263 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |13.0 Priority|P3 |P1
[Bug modula2/108259] Modula-2 module constructors symbols in (shared) libraries are hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108259 Iain Sandoe changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-January ||/609298.html --- Comment #4 from Iain Sandoe --- posted patch, it seems an incremental improvement - although subsidiary issues remain.
[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=znver3 since r13-4685-g4834e9360f7bf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- In Fedora test mass rebuild this seems to be the most common ICE: ./UNCONFIRMED/fedora-rawhide-ppc64le/llvm8.0/05172811-llvm8.0/build.log.gz /usr/include/c++/13/bits/stl_algo.h:4103:29: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-ppc64le/chatterino2/05168380-chatterino2/build.log.gz /usr/include/c++/13/bits/stl_iterator_base_funcs.h:106:21: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-ppc64le/pdns-recursor/05174194-pdns-recursor/build.log.gz /usr/include/boost/circular_buffer/base.hpp:2824:46: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-ppc64le/krita/05171764-krita/build.log.gz /usr/include/boost/range/iterator_range_core.hpp:408:28: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-ppc64le/root/05185147-root/build.log.gz /usr/include/c++/13/bits/stl_algo.h:4103:29: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-ppc64le/python-graph-tool/05175233-python-graph-tool/build.log.gz src/graph/generation/graph_rewiring.hh:106:5: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-ppc64le/pcl/05174165-pcl/build.log.gz /usr/include/boost/circular_buffer/base.hpp:1787:46: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-ppc64le/innoextract/05171222-innoextract/build.log.gz /usr/include/boost/preprocessor/iteration/detail/limits/local_256.hpp:22:9: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 /usr/include/boost/preprocessor/iteration/detail/limits/local_256.hpp:22:9: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-ppc64le/QuantLib/05167497-QuantLib/build.log.gz /usr/include/c++/13/bits/stl_iterator_base_funcs.h:106:21: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-ppc64le/llvm9.0/05172812-llvm9.0/build.log.gz /usr/include/c++/13/bits/stl_algo.h:4103:29: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-s390x/llvm8.0/05172811-llvm8.0/build.log.gz /usr/include/c++/13/bits/stl_algo.h:4103:29: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-s390x/chatterino2/05168380-chatterino2/build.log.gz /usr/include/c++/13/bits/stl_iterator_base_funcs.h:106:21: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-s390x/pdns-recursor/05174194-pdns-recursor/build.log.gz /usr/include/boost/circular_buffer/base.hpp:2824:46: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-s390x/krita/05171764-krita/build.log.gz /usr/include/boost/range/iterator_range_core.hpp:408:28: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 /usr/include/boost/range/iterator_range_core.hpp:408:28: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-s390x/root/05185147-root/build.log.gz /usr/include/c++/13/bits/stl_algo.h:4103:29: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-s390x/python-graph-tool/05175233-python-graph-tool/build.log.gz src/graph/generation/graph_rewiring.hh:106:5: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-s390x/pcl/05174165-pcl/build.log.gz /usr/include/boost/circular_buffer/base.hpp:1787:46: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-s390x/innoextract/05171222-innoextract/build.log.gz /usr/include/boost/preprocessor/iteration/detail/limits/local_256.hpp:22:9: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 /usr/include/boost/preprocessor/iteration/detail/limits/local_256.hpp:22:9: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-s390x/QuantLib/05167497-QuantLib/build.log.gz /usr/include/c++/13/bits/stl_iterator_base_funcs.h:106:21: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-s390x/llvm9.0/05172812-llvm9.0/build.log.gz /usr/include/c++/13/bits/stl_algo.h:4103:29: internal compiler error: in modify_call, at ipa-param-manipulation.cc:700 ./UNCONFIRMED/fedora-rawhide-i386/krita/05171764-krita/build.log.gz /usr/incl
[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183 Iain Sandoe changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-January ||/609299.html --- Comment #20 from Iain Sandoe --- posted the second patch, as I now figured out the open question about CTORs generated from ,mod files.
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 --- Comment #8 from Jürgen Reuter --- What is the status of this problem? I checked with Darwin 22.2 and XCode 14.2, and the problem still persists with the Git master, cf. below. Is there a workaround for the moment? Will this be resolved before the release of gcc14? /usr/local/packages/gcc_trunk/_build/./prev-gcc/xg++ -B/usr/local/packages/gcc_trunk/_build/./prev-gcc/ -B/usr/local/x86_64-apple-darwin22.2.0/bin/ -nostdinc++ -B/usr/local/packages/gcc_trunk/_build/prev-x86_64-apple-darwin22.2.0/libstdc++-v3/src/.libs -B/usr/local/packages/gcc_trunk/_build/prev-x86_64-apple-darwin22.2.0/libstdc++-v3/libsupc++/.libs -I/usr/local/packages/gcc_trunk/_build/prev-x86_64-apple-darwin22.2.0/libstdc++-v3/include/x86_64-apple-darwin22.2.0 -I/usr/local/packages/gcc_trunk/_build/prev-x86_64-apple-darwin22.2.0/libstdc++-v3/include -I/usr/local/packages/gcc_trunk/libstdc++-v3/libsupc++ -L/usr/local/packages/gcc_trunk/_build/prev-x86_64-apple-darwin22.2.0/libstdc++-v3/src/.libs -L/usr/local/packages/gcc_trunk/_build/prev-x86_64-apple-darwin22.2.0/libstdc++-v3/libsupc++/.libs -I../../libcpp -I. -I../../libcpp/../include -I./../intl -I../../libcpp/include -g -O2 -fno-checking -gtoggle -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -fno-exceptions -fno-rtti -I../../libcpp -I. -I../../libcpp/../include -I./../intl -I../../libcpp/include-c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../libcpp/charset.cc ../../libcpp/charset.cc: In function ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_string_location_reader*, cpp_substring_ranges*)’: ../../libcpp/charset.cc:2207:18: error: ‘int sprintf(char*, const char*, ...)’ is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror=deprecated-declarations] 2207 | sprintf(buf, "%03o", (int) c); | ~~~^~ In file included from ../../libcpp/system.h:38, from ../../libcpp/charset.cc:21: /usr/local/packages/gcc_trunk/_build/prev-gcc/include-fixed/stdio.h:204:10: note: declared here 204 | int sprintf(char * __restrict, const char * __restrict, ...) __printflike(2, 3); | ^~~
[Bug modula2/108182] gm2 driver mishandles target and multilib options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182 --- Comment #2 from Iain Sandoe --- computing the multilib_os_dir in the language driver is not going to be easy/reliably correct, since that code is called very early and the specs applied later could well modify the command line options. On IRC I had suggested that to mitigate thus it might be possible to defer the computation by using the "%M" spec to insert the relevant multilib_os_dir entries. However, that would mean moving the production of the -I command line entries to a language spec. At the moment I cannot see how to implement that - since there are no specs to substitute for $libdir etc. So, at present, ISTM that the most reliable approach would be to follow what the c-fmaily does and compute the language-specific include paths early in the front end. As noted in PR108259, the '-L' entries are not, in fact, needed (actually they break the discovery of the shared libraries) so that this part of the process can be simplified (and there is no need to consider the pre-link callback we were discussing). It seems increasingly likely that simplifying the library to a single runtime with the process of deciding which APIs are available decided by the FE is probably going to resolve a bunch of difficulties and simplify the driver at the same time (0.02GBP, only, no patches at this time).
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |13.0 --- Comment #9 from Iain Sandoe --- (I don't have a macOS13 setup yet, limited hardware available here) ... so, if it is not fixed in the Xcode 14.x releases, we'll have to work around it in the GCC sources. Work-around is to add this to the 'make' command line. BOOT_CFLAGS="-O2 -g -Wno-error=deprecated-declarations" I think we can arrange for that to be added automatically to the build flags, it is intended to deal with this before 13 branches.
[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=znver3 since r13-4685-g4834e9360f7bf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comment #14 from Sergei Trofimovich ---
Got a similar ICE on minetest-5.6.1. With a bit of manual cleanup reduced down
to the following:
//$ cat bug.cc
void __throw_out_of_range_fmt(...);
char *_M_p;
struct Trans_NS___cxx11_basic_string {
long _M_string_length;
long _M_check___pos;
Trans_NS___cxx11_basic_string() {
long __length = 0;
_M_string_length = __length;
}
long size() { return _M_string_length; }
long foo___pos;
char foo() { return _M_p[foo___pos]; }
int compare() { __throw_out_of_range_fmt(_M_check___pos, _M_string_length);
__builtin_trap(); }
};
bool str_starts_with(Trans_NS___cxx11_basic_string &str,
Trans_NS___cxx11_basic_string prefix) {
if (str.size() < prefix.size())
str.compare();
for (; prefix.size();) {
char __trans_tmp_2 = prefix.foo();
if (__trans_tmp_2)
return false;
}
__builtin_trap();
}
void testStartsWith() {
Trans_NS___cxx11_basic_string s1, s2;
str_starts_with(s1, s2);
}
$ g++ -Wall -Wextra -O3 -c bug.cc
during IPA pass: inline
bug.cc: In function 'void testStartsWith()':
bug.cc:28:18: internal compiler error: in modify_call, at
ipa-param-manipulation.cc:700
28 | str_starts_with(s1, s2);
| ~~~^~~~
0x1cbdfd4 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x1cbec26 internal_error(char const*, ...)
???:0
0x753df0 fancy_abort(char const*, int, char const*)
???:0
0x723afe ipa_param_adjustments::modify_call(cgraph_edge*, bool) [clone .cold]
???:0
0xa4e735 cgraph_edge::redirect_call_stmt_to_callee(cgraph_edge*)
???:0
0xec8a13 redirect_all_calls(copy_body_data*, basic_block_def*)
???:0
0xece256 copy_body(copy_body_data*, basic_block_def*, basic_block_def*,
basic_block_def*) [clone .isra.0]
???:0
0xed1ded expand_call_inline(basic_block_def*, gimple*, copy_body_data*,
bitmap_head*)
???:0
0xed3b69 optimize_inline_calls(tree_node*)
???:0
0xc3f753 inline_transform(cgraph_node*)
???:0
0xd8d1ff execute_all_ipa_transforms(bool)
???:0
0xa54b3f cgraph_node::expand()
???:0
0xa5604d symbol_table::compile() [clone .part.0]
???:0
0xa58517 symbol_table::finalize_compilation_unit()
???:0
[Bug rtl-optimization/108263] [13 Regression] ICE building Linux kernel on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108263 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-01-02 --- Comment #1 from Jakub Jelinek --- Created attachment 54174 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54174&action=edit gcc13-pr108263.patch Untested fix.
[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-01-02 Status|UNCONFIRMED |NEW --- Comment #4 from Iain Sandoe --- (marking as New since I can repeat this on more than one platform) one other datum: adding -fscaffold-static makes the shared library version work on both Linux and Darwin, which seems to support the hypothesis that the problem is to do with how dynamic initialisation is constructed.
[Bug middle-end/108264] New: [11/12/13 Regression] ICE compiling guacamole-server on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108264
Bug ID: 108264
Summary: [11/12/13 Regression] ICE compiling guacamole-server
on s390x-linux
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
int v;
extern int bar (void);
static inline void
foo (char *d)
{
switch (bar ())
{
case 2:
d[0] = d[1] = d[2] = d[3] = v;
break;
case 4:
d[0] = 0;
}
}
int
baz (int x)
{
foo ((char *) &x);
return x;
}
ICEs with -O2 -march=z13 -fpic (in 11 with -O2 -ftree-vectorize -march=z13
-fpic) in:
during RTL pass: expand
dump file: guacamole-ice.i.254r.expand
In function ‘foo’,
inlined from ‘baz’ at guacamole-ice.i:20:3:
guacamole-ice.i:10:12: internal compiler error: in convert_move, at expr.cc:297
10 | d[0] = d[1] = d[2] = d[3] = v;
| ~^~~~
This is when expanding
_2 = {_6, _6, _6, _6};
MEM [(char *)&x] = _2;
where
vector(4) char _2;
and x is int PARM_DECL.
to in convert_move is (reg/v:DI 66 [ x+-4 ]) and from is (reg:V4QI 70) , so the
modes have different sizes. But x is actually int and so the DImode is
argument promotion.
[Bug middle-end/108264] [11/12/13 Regression] ICE compiling guacamole-server on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108264 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||krebbel at gcc dot gnu.org Ever confirmed|0 |1 Priority|P3 |P2 Last reconfirmed||2023-01-02 Target||s390x-linux Target Milestone|--- |11.4
[Bug middle-end/108264] [11/12/13 Regression] ICE compiling guacamole-server on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108264 --- Comment #1 from Jakub Jelinek --- store_expr is called with target (subreg/s/u:SI (reg/v:DI 66 [ x+-4 ]) 4) where the mode is still correct...
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 --- Comment #10 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #9) > (I don't have a macOS13 setup yet, limited hardware available here) > > ... so, if it is not fixed in the Xcode 14.x releases, we'll have to work > around it in the GCC sources. > > Work-around is to add this to the 'make' command line. > > BOOT_CFLAGS="-O2 -g -Wno-error=deprecated-declarations" > > I think we can arrange for that to be added automatically to the build > flags, it is intended to deal with this before 13 branches. Hm, this doesn't work for me, neither when adding to the configure line nor when adding it to the make command. Sorry for being ignorant, but how do I have to apply this?
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 --- Comment #11 from Iain Sandoe --- at what stage is it failing? (and with what error) .. when I las tried this with the macOS13 SDK it dod work .. I will try to fit a test run in sometime (stuff is tied up with other testing right now)
[Bug middle-end/108264] [11/12/13 Regression] ICE compiling guacamole-server on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108264 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 54175 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54175&action=edit gcc13-pr108264.patch Untested fix.
[Bug libstdc++/108265] New: chrono::hh_mm_ss can't be constructed from unsigned durations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108265
Bug ID: 108265
Summary: chrono::hh_mm_ss can't be constructed from unsigned
durations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mwd at md5i dot com
Target Milestone: ---
chrono::hh_mm_ss can't be constructed from unsigned durations.
For example:
#include
int main()
{
std::chrono::duration dur{};
auto hms = std::chrono::hh_mm_ss(dur);
}
This fails because the hh_mm_ss constructor calls chrono::abs on the passed in
duration, and chrono::abs doesn't participate in overload resolution when the
duration is unsigned.
[Bug c++/108266] New: [13 Regression] ICE during cxx_eval_constant_expression on IMPLICIT_CONV_EXPR since r13-4564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108266
Bug ID: 108266
Summary: [13 Regression] ICE during
cxx_eval_constant_expression on IMPLICIT_CONV_EXPR
since r13-4564
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
#include
#include
struct S { S (const char *); };
void bar (std::vector);
template
void
foo ()
{
bar ({"", ""});
}
void
baz ()
{
foo<0> ();
}
ICEs with -std=c++20 starting with
r13-4564-gd081807d8d70e3e87eae41e1560e54d503f4d465
internal compiler error: unexpected expression '(S)""' of kind
implicit_conv_expr
11 | bar ({"", ""});
| ^~
In Fedora test mass rebuilds I saw 33 ICEs like that.
Instead of the includes one can use just
namespace std {
template struct initializer_list { const T *ptr; decltype (sizeof 0)
len; };
template struct vector { vector (initializer_list); };
}
to get the same ICE.
The problem is that maybe_init_list_as_range -> maybe_init_list_as_array ->
maybe_constant_init is called when processing_template_decl (from
build_user_type_conversion_1). Wonder if the call shouldn't be skipped for
processing_template_decl, or whether say maybe_init_list_as_range shouldn't
always return NULL if processing_template_decl.
[Bug c++/108266] [13 Regression] ICE during cxx_eval_constant_expression on IMPLICIT_CONV_EXPR since r13-4564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108266 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org Last reconfirmed||2023-01-02 Target Milestone|--- |13.0 Status|UNCONFIRMED |NEW Priority|P3 |P1 Ever confirmed|0 |1
[Bug target/87832] AMD pipeline models are very costly size-wise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832 --- Comment #13 from CVS Commits --- The master branch has been updated by Alexander Monakov : https://gcc.gnu.org/g:ec1db9017939bb8289c9bd63aace66c0f3957ecd commit r13-4956-gec1db9017939bb8289c9bd63aace66c0f3957ecd Author: Alexander Monakov Date: Fri Dec 9 20:47:55 2022 +0300 i386: correct division modeling in lujiazui.md Model the divider in Lujiazui processors as a separate automaton to significantly reduce the overall model size. This should also result in improved accuracy, as pipe 0 should be able to accept new instructions while the divider is occupied. It is unclear why integer divisions are modeled as if pipes 0-3 are all occupied. I've opted to keep a single-cycle reservation of all four pipes together, so GCC should continue trying to pack instructions around a division accordingly. Currently top three symbols in insn-automata.o are: 106102 r lujiazui_core_check 106102 r lujiazui_core_transitions 196123 r lujiazui_core_min_issue_delay This patch shrinks all lujiazui tables to: 3 r lujiazui_decoder_min_issue_delay 20 r lujiazui_decoder_transitions 32 r lujiazui_agu_min_issue_delay 126 r lujiazui_agu_transitions 304 r lujiazui_div_base 352 r lujiazui_div_check 352 r lujiazui_div_transitions 1152 r lujiazui_core_min_issue_delay 1592 r lujiazui_agu_translate 1592 r lujiazui_core_translate 1592 r lujiazui_decoder_translate 1592 r lujiazui_div_translate 3952 r lujiazui_div_min_issue_delay 9216 r lujiazui_core_transitions This continues the work on reducing i386 insn-automata.o size started with similar fixes for division and multiplication instructions in znver.md. gcc/ChangeLog: PR target/87832 * config/i386/lujiazui.md (lujiazui_div): New automaton. (lua_div): New unit. (lua_idiv_qi): Correct unit in the reservation. (lua_idiv_qi_load): Ditto. (lua_idiv_hi): Ditto. (lua_idiv_hi_load): Ditto. (lua_idiv_si): Ditto. (lua_idiv_si_load): Ditto. (lua_idiv_di): Ditto. (lua_idiv_di_load): Ditto. (lua_fdiv_SF): Ditto. (lua_fdiv_SF_load): Ditto. (lua_fdiv_DF): Ditto. (lua_fdiv_DF_load): Ditto. (lua_fdiv_XF): Ditto. (lua_fdiv_XF_load): Ditto. (lua_ssediv_SF): Ditto. (lua_ssediv_load_SF): Ditto. (lua_ssediv_V4SF): Ditto. (lua_ssediv_load_V4SF): Ditto. (lua_ssediv_V8SF): Ditto. (lua_ssediv_load_V8SF): Ditto. (lua_ssediv_SD): Ditto. (lua_ssediv_load_SD): Ditto. (lua_ssediv_V2DF): Ditto. (lua_ssediv_load_V2DF): Ditto. (lua_ssediv_V4DF): Ditto. (lua_ssediv_load_V4DF): Ditto.
[Bug c++/108047] [13 Regression] ICE: unexpected expression of kind implicit_conv_expr since r13-4564-gd081807d8d70e3e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047 Andrew Pinski changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Andrew Pinski --- *** Bug 108266 has been marked as a duplicate of this bug. ***
[Bug c++/108266] [13 Regression] ICE during cxx_eval_constant_expression on IMPLICIT_CONV_EXPR since r13-4564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108266 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 108047 *** This bug has been marked as a duplicate of bug 108047 ***
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 --- Comment #12 from Iain Sandoe --- with Xcode 14.1 CLT and the macOS13 SDK, the build fails without the work-around and works for this: time nice make -j10 BOOT_CFLAGS="-O2 -g -Wno-error=deprecated-declarations" >b.txt 2>e.txt (jftr) configure line is: /src-local/gcc-master/configure --prefix=/opt/iains/x86_64-apple-darwin21/gcc-13-0-0 --build=x86_64-apple-darwin21 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk CC=x86_64-apple-darwin19-gcc CXX=x86_64-apple-darwin19-g++ --enable-languages=all >conf.txt and the source is current master. (OK, so the differences are [1] I am on macOS12 and [2] I'm using Xcode 14.1 CLT,but the fail and fix are completely repeatable here). Next, I guess I'll pick up the xc 14.2 release.
[Bug libstdc++/108260] __cpp_lib_ranges_zip feature test macro not defined while std::views::zip is supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108260 --- Comment #1 from Jonathan Wakely --- (In reply to rhalbersma from comment #0) > I'm a happy user of std::views::zip in gcc-latest but AFAICS the feature > test macro __cpp_lib_ranges_zip is not yet defined, neither in , > , , nor in . This makes it hard #ifdedf my code on > this feature. I'm not sure if the feature is actually complete yet. It wasn't all done in a single patch. > Just for my curiosity: is it generally the case that feature test macros are > being added along with the feature completeness? Or should I condition my > mixed C++20/C++23 code in another way? This should be pretty obvious from looking at . GCC has always led the way in defining feature test macros.
[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235 --- Comment #4 from John David Anglin --- Working on a patch to add support for sync libfuncs. Downside is one needs to add -fno-sync-libcalls to generate calls for libatomic. I think the HP implementations of pthread_mutex_lock and pthread_mutex_unlock in libpthread are better than what I will do for the sync routines. That's why I haven't implemented the sync routines before. Is there an alternative?
ICE on trunk with combination of "-Og -fcontracts", repro link in body
Hit the following ICE today, just sharing here to be helpful: https://gcc.godbolt.org/z/advKKxK43 during RTL pass: final : In member function 'void Stack::push(int)': :20:3: internal compiler error: in gen_inlined_subroutine_die, at dwarf2out.cc:25002 20 | } | ^
Re: ICE on trunk with combination of "-Og -fcontracts", repro link in body
Please file a bug to bugzilla. With attaching the source there. This list is for automated emails from bugzilla really and most folks are not tracking the list. Thanks, Andrew On Mon, Jan 2, 2023 at 10:16 AM Gavin Ray via Gcc-bugs wrote: > > Hit the following ICE today, just sharing here to be helpful: > > https://gcc.godbolt.org/z/advKKxK43 > > during RTL pass: final > : In member function 'void Stack::push(int)': > :20:3: internal compiler error: in gen_inlined_subroutine_die, at > dwarf2out.cc:25002 >20 | } > | ^
[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235 --- Comment #5 from Jonathan Wakely --- tzdb.cc doesn't need atomics, it can just work with a mutex. I'm still on holiday until tomorrow though.
Re: ICE on trunk with combination of "-Og -fcontracts", repro link in body
I tried but it won't allow me to create an issue on the bugzilla, it says "account creation is not allowed at this time" On Mon, Jan 2, 2023 at 1:17 PM Andrew Pinski wrote: > Please file a bug to bugzilla. With attaching the source there. > This list is for automated emails from bugzilla really and most folks > are not tracking the list. > > Thanks, > Andrew > > On Mon, Jan 2, 2023 at 10:16 AM Gavin Ray via Gcc-bugs > wrote: > > > > Hit the following ICE today, just sharing here to be helpful: > > > > https://gcc.godbolt.org/z/advKKxK43 > > > > during RTL pass: final > > : In member function 'void Stack::push(int)': > > :20:3: internal compiler error: in gen_inlined_subroutine_die, at > > dwarf2out.cc:25002 > >20 | } > > | ^ >
Re: ICE on trunk with combination of "-Og -fcontracts", repro link in body
On Mon, Jan 2, 2023 at 10:21 AM Gavin Ray wrote: > > I tried but it won't allow me to create an issue on the bugzilla, it says > "account creation is not allowed at this time" Directly from https://gcc.gnu.org/bugzilla/createaccount.cgi : "Because of spam, account creation through this form is restricted. If creating an account fails, contact gcc-bugzilla-account-requ...@gcc.gnu.org to request a GCC Bugzilla account. You should receive a response within 24 hours." Thanks, Andrew Pinski > > On Mon, Jan 2, 2023 at 1:17 PM Andrew Pinski wrote: >> >> Please file a bug to bugzilla. With attaching the source there. >> This list is for automated emails from bugzilla really and most folks >> are not tracking the list. >> >> Thanks, >> Andrew >> >> On Mon, Jan 2, 2023 at 10:16 AM Gavin Ray via Gcc-bugs >> wrote: >> > >> > Hit the following ICE today, just sharing here to be helpful: >> > >> > https://gcc.godbolt.org/z/advKKxK43 >> > >> > during RTL pass: final >> > : In member function 'void Stack::push(int)': >> > :20:3: internal compiler error: in gen_inlined_subroutine_die, at >> > dwarf2out.cc:25002 >> >20 | } >> > | ^
Re: ICE on trunk with combination of "-Og -fcontracts", repro link in body
Got it, I'll email that account and hopefully get things sorted out then -- thanks Andrew and Happy New Year to you! On Mon, Jan 2, 2023 at 1:33 PM Andrew Pinski wrote: > On Mon, Jan 2, 2023 at 10:21 AM Gavin Ray wrote: > > > > I tried but it won't allow me to create an issue on the bugzilla, it > says "account creation is not allowed at this time" > > Directly from https://gcc.gnu.org/bugzilla/createaccount.cgi : > "Because of spam, account creation through this form is restricted. If > creating an account fails, contact > gcc-bugzilla-account-requ...@gcc.gnu.org to request a GCC Bugzilla > account. You should receive a response within 24 hours." > > Thanks, > Andrew Pinski > > > > > On Mon, Jan 2, 2023 at 1:17 PM Andrew Pinski wrote: > >> > >> Please file a bug to bugzilla. With attaching the source there. > >> This list is for automated emails from bugzilla really and most folks > >> are not tracking the list. > >> > >> Thanks, > >> Andrew > >> > >> On Mon, Jan 2, 2023 at 10:16 AM Gavin Ray via Gcc-bugs > >> wrote: > >> > > >> > Hit the following ICE today, just sharing here to be helpful: > >> > > >> > https://gcc.godbolt.org/z/advKKxK43 > >> > > >> > during RTL pass: final > >> > : In member function 'void Stack::push(int)': > >> > :20:3: internal compiler error: in > gen_inlined_subroutine_die, at > >> > dwarf2out.cc:25002 > >> >20 | } > >> > | ^ >
[Bug target/108267] New: [13 Regression] Bootstrap failure on aarch64-linux since r13-4953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108267
Bug ID: 108267
Summary: [13 Regression] Bootstrap failure on aarch64-linux
since r13-4953
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
My aarch64 bootstrap fails with:
../../../libgcc/unwind-dw2.c: In function 'init_dwarf_reg_size_table':
../../../libgcc/unwind-dw2.c:1334:3: error: this operation requires the SVE ISA
extension
1334 | __builtin_init_dwarf_reg_size_table (dwarf_reg_size_table);
| ^~
../../../libgcc/unwind-dw2.c:1334:3: note: you can enable SVE using the
command-line option '-march', or by using the 'target' attribute or pragma
../../../libgcc/unwind-dw2.c:1334: confused by earlier errors, bailing out
Trying to compile even simple:
static unsigned char dwarf_reg_size_table[__LIBGCC_DWARF_FRAME_REGISTERS__+1];
void
foo (void)
{
__builtin_init_dwarf_reg_size_table (dwarf_reg_size_table);
}
with -O2 -nostdinc -fbuilding-libgcc before that change used to give different
results between when SVE was on and when it wasn't (v0 .. v31 registers get
dwarf_reg_size_table[32 .. 63] = 8 when unwind-dw2.o is compiled without SVE
and
result of cntd with it (it isn't clear to me how this is supposed to work
because clearly unwind-dw2.o compiled with SVE can't be used on CPUs without
SVE), but now
it just ICEs without SVE:
./cc1 -quiet -O2 -nostdinc a.c -fbuilding-libgcc -o a.s2
a.c: In function ‘foo’:
a.c:6:3: error: this operation requires the SVE ISA extension
6 | __builtin_init_dwarf_reg_size_table (dwarf_reg_size_table);
| ^~
a.c:6:3: note: you can enable SVE using the command-line option ‘-march’, or by
using the ‘target’ attribute or pragma
during RTL pass: expand
a.c:6:3: internal compiler error: Segmentation fault
0x1567ab0 crash_signal
../../gcc/toplev.cc:314
0xdc56ff single_set(rtx_insn const*)
../../gcc/rtl.h:3594
0xfd150c emit_move_insn(rtx_def*, rtx_def*)
../../gcc/expr.cc:4345
0xf9f8b6 force_reg(machine_mode, rtx_def*)
../../gcc/explow.cc:688
0x23040e7 gen_movqi(rtx_def*, rtx_def*)
../../gcc/config/aarch64/aarch64.md:1207
0xe02abe rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
../../gcc/recog.h:407
0xfd09c1 emit_move_insn_1(rtx_def*, rtx_def*)
../../gcc/expr.cc:4172
0xfd14e5 emit_move_insn(rtx_def*, rtx_def*)
../../gcc/expr.cc:4342
0xef7e00 expand_builtin_init_dwarf_reg_sizes(tree_node*)
../../gcc/dwarf2cfi.cc:380
[Bug target/108267] [13 Regression] Bootstrap failure on aarch64-linux since r13-4953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108267 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |13.0 Priority|P3 |P1
[Bug target/108267] [13 Regression] Bootstrap failure on aarch64-linux since r13-4953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108267 Andrew Pinski changed: What|Removed |Added Severity|normal |blocker Keywords||build, ice-on-valid-code, ||rejects-valid
[Bug target/108267] [13 Regression] Bootstrap failure on aarch64-linux since r13-4953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108267 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107678 --- Comment #1 from Andrew Pinski --- Pr 107678 is related where there was a mismatch at runtime.
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 --- Comment #13 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #12) . > > Next, I guess I'll pick up the xc 14.2 release. Sorry, my bad, I misplaced the position of the argument BOOT_CFLAGS, I erroneously (like for configure, where it doesn't matter) in front of the make command, not after the make command. In the second case, it works.
[Bug target/98112] Add -f[no-]direct-access-external-data & drop HAVE_LD_PIE_COPYRELOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #8 from James Y Knight --- The requested semantics were subsequently implemented by GCC as `-mno-direct-extern-access` in PR100593, is that right? (Except that it was done only for x86-64, rather than being arch-independent.) So maybe this PR should be closed?
[Bug middle-end/108268] New: [13 Regression] Build failure on cross from powerpc64le-linux to nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108268 Bug ID: 108268 Summary: [13 Regression] Build failure on cross from powerpc64le-linux to nvptx-none Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- ../configure --disable-bootstrap --disable-sjlj-exceptions --enable-newlib-io-long-long --with-build-time-tools=/builddir/build/BUILD/gcc-13.0.0-20230102/obji/usr/nvptx-none/bin -- target nvptx-none --enable-as-accelerator-for=ppc64le-redhat-linux --enable-languages=c,c++,fortran,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl= http://bugzilla.redhat.com/bugzilla --enable-checking=release --with-system-zlib --with-gcc-major-version-only --without-isl configured GCC ICEs on compilation of all C/C++ files. The problem is that c_cpp_builtins function has &c_global_trees[0] value stored in $r30 register, but when it calls 1525int value = dwarf_reg_sizes_constant (); the $r30 value is saved into stack frame and partially overwritten by buffer overflow. Before it is 0x11939cb0 and after returning from that function 0x11930008. This is because DWARF_FRAME_RETURN_COLUMN macro defaults to DWARF_FRAME_REGISTERS, nvptx.h doesn't override it (it is a target without register allocation nor debug info), dwarf_reg_sizes_constant allocates 343 poly_uint16 *sizes = XALLOCAVEC (poly_uint16, DWARF_FRAME_REGISTERS); and then generate_dwarf_reg_sizes stores: 326 if (!init_state.wrote_return_column) 327 sizes[DWARF_FRAME_RETURN_COLUMN] = GET_MODE_SIZE (Pmode);
[Bug middle-end/108268] [13 Regression] Build failure on cross from powerpc64le-linux to nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108268 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |13.0 Priority|P3 |P1 CC||fw at gcc dot gnu.org
[Bug middle-end/108268] [13 Regression] Build failure on cross from powerpc64le-linux to nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108268 Andrew Pinski changed: What|Removed |Added Keywords||build Severity|normal |blocker
[Bug c++/108269] New: Incorrect __PRETTY_FUNCTION__ with std::array in C++20 NTTP literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108269
Bug ID: 108269
Summary: Incorrect __PRETTY_FUNCTION__ with std::array in
C++20 NTTP literal
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: camden.mannett at gmail dot com
Target Milestone: ---
Created attachment 54176
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54176&action=edit
Source code
When std::array is used within a literal type that is used as an NTTP,
it _looks_ like the __PRETTY_FUNCTION__ output always assumes that it is a
null-terminated string which is then displayed without the last character - but
it is not always a null!
It is simplest to demonstrate with a compile-time string implementation
(https://godbolt.org/z/8EnPfeWq7):
#include
#include
#include
namespace {
template
class type_string_t
{
[[nodiscard]] constexpr static std::string_view generate() noexcept
{
constexpr auto sig =
std::string_view{ static_cast(__PRETTY_FUNCTION__) };
return sig;
}
public:
constexpr static auto value = generate();
};
template
constexpr auto type_string = type_string_t::value;
template
class str_storage
{
public:
constexpr str_storage(const char (&str)[N])
{
std::copy_n(&str[0], N, value.begin());
}
constexpr str_storage(char c)
: value{ c }
{
}
std::array value;
};
str_storage(char) -> str_storage<1>;
template
struct str
{};
}
int
main()
{
std::cout << type_string> << "\n"
<< type_string> << "\n"
<< type_string> << std::endl;
return 0;
}
This yields pretty much what you would expect when built via Clang (after
removal of cruft):
(anonymous namespace)::str<{{{97}}}>
(anonymous namespace)::str<{{"a"}}>
(anonymous namespace)::str<{{"hello"}}>
However gcc does something different when the std::array contains only a single
char:
{anonymous}::str<{anonymous}::str_storage<1>{std::array{""}}>
{anonymous}::str<{anonymous}::str_storage<2>{std::array{"a"}}>
{anonymous}::str<{anonymous}::str_storage<6>{std::array{"hello"}}>
It seems to always represent the char array as a null-terminated string
literal, which isn't always true.
[Bug tree-optimization/105216] [12/13 regression] 8% regression for m-queens compared to gcc11 O2 on CLX. since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105216 --- Comment #16 from Hongtao.liu --- (In reply to Andrew Pinski from comment #15) > Might be interesting to test it again to see if it has been fixed on the > trunk. The regression is still there. gcc version 13.0.0 20230102 (experimental) (GCC)
[Bug c++/108269] __PRETTY_FUNCTION__ for NTTP literal intiailization containing a char array is assumed to ending in a null character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108269
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-01-03
Ever confirmed|0 |1
Summary|Incorrect |__PRETTY_FUNCTION__ for
|__PRETTY_FUNCTION__ with|NTTP literal intiailization
|std::array in C++20 |containing a char array is
|NTTP literal|assumed to ending in a null
||character
--- Comment #1 from Andrew Pinski ---
type_string>
Works though:
static constexpr std::string_view {anonymous}::type_string_t::generate()
[with T = {anonymous}::str<{anonymous}::str_storage<8>{std::array{"hello\000\001"}}>; std::string_view = std::basic_string_view]
Oh the problem is just char ending not in a null character.
Reduced testcase:
template
struct type_string_t
{
constexpr static auto generate() noexcept
{
return __PRETTY_FUNCTION__;
}
};
template
struct t
{
char a[N];
};
int
main()
{
__builtin_printf("%s\n", type_string_t::generate());
return 0;
}
[Bug c++/108269] __PRETTY_FUNCTION__ for NTTP literal intiailization containing a char array is assumed to ending in a null character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108269 --- Comment #2 from Andrew Pinski --- Note this is just a problem with __PRETTY_FUNCTION__/__func__ and not an ABI issue as it is done correctly for the mangling. So it is just a minor issue dealing with debugging really because __PRETTY_FUNCTION__/__func__ format does not have any standard way of describing what it is.
[Bug ipa/108250] [12/13 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250 --- Comment #10 from Sam James --- Both Arsen and I gave it a go and it doesn't seem to make a difference either way (it doesn't induce miscompilation with the revert, and it doesn't fix miscompilation without the revert).
[Bug c++/108269] __PRETTY_FUNCTION__ for NTTP literal intiailization containing a char array is assumed to ending in a null character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108269 --- Comment #3 from Andrew Pinski --- __PRETTY_FUNCTION__ is also a GCC extension too so ...
[Bug c/108270] New: un-optimal vsetvl for multi-loop if avl is 0 ~ 31 immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108270
Bug ID: 108270
Summary: un-optimal vsetvl for multi-loop if avl is 0 ~ 31
immediate
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
Consider this following case:
#include "riscv_vector.h"
void f1 (void * restrict in, void * restrict out, int l, int n, int m)
{
for (int i = 0; i < l; i++){
for (int j = 0; j < m; j++){
for (int k = 0; k < n; k++)
{
vint8mf8_t v = __riscv_vle8_v_i8mf8 (in + i + j, 17);
__riscv_vse8_v_i8mf8 (out + i + j, v, 17);
}
}
}
}
GCC ASM:
f1:
0: mv a7,a2
1: mv a6,a0
2: mv t1,a1
3: mv a2,a3
4: vsetivlizero,17,e8,mf8,ta,ma
5: ble a7,zero,.L1
6: ble a4,zero,.L1
7: ble a3,zero,.L1
8: add a1,a0,a4
9: li a0,0
10:.L4:
11: add a3,a6,a0
12: add a4,t1,a0
13:.L7:
14: li a5,0
15:.L5:
16: vle8.v v24,0(a3)
17: addiw a5,a5,1
18: vse8.v v24,0(a4)
19: bne a2,a5,.L5
20: addia3,a3,1
21: addia4,a4,1
22: bne a3,a1,.L7
23: addia0,a0,1
24: addia1,a1,1
25: bne a0,a7,.L4
26:.L1:
27: ret
The vsetivli instruction is hoisted too early. The best location of vsetivli
should be any point from 8 to 9.
[Bug c/108270] un-optimal vsetvl for multi-loop if avl is 0 ~ 31 immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108270 JuzheZhong changed: What|Removed |Added CC||juzhe.zhong at rivai dot ai --- Comment #1 from JuzheZhong --- This is a trivial issue. I will fix it later.
[Bug target/108185] [RISC-V]RVV assemble not set vsetvli correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185 --- Comment #3 from jiawei --- (In reply to Kito Cheng from comment #2) > It seems right to me? Yes, It have the same behavior with clang, but it could generate better assemble code like: vl1re8.vv24,0(a0) addi a4,a1,800 vs1r.v v24,0(a1) vsetvli a5,zero,e8,m1,ta,ma vlm v24,0(a0) vsm v24,0(a4) ret > > > ``` > $ riscv64-unknown-elf-gcc pr108185.c -march=rv64gcv -mabi=lp64d -O3 -S -o > - > .file "pr108185.c" > .option nopic > .attribute arch, > "rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1 > p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0" > .attribute unaligned_access, 0 > .attribute stack_align, 16 > .text > .align 1 > .globl foo5_3 > .type foo5_3, @function > foo5_3: > csrrt0,vlenb > sllit1,t0,1 > csrra5,vlenb > sub sp,sp,t1 > sllia3,a5,1 > add a3,a3,sp > vl1re8.vv25,0(a0) # Load value from *(vint8m1_t*)in > sub a5,a3,a5 > vs1r.v v25,0(a1) # Store value to *(vint8m1_t*)out > vs1r.v v25,0(a5) # Store value to stack, although it's > unused. > addia4,a1,800 > csrrt0,vlenb > sllit1,t0,1 > vsetvli a5,zero,e8,m1,ta,ma # Right vsetvli for vsm.v > vsm.v v25,0(a4) > add sp,sp,t1 > jr ra > .size foo5_3, .-foo5_3 > .ident "GCC: (g44b22ab81cf) 13.0.0 20221229 (experimental)" > ```
[Bug target/108240] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 Kewen Lin changed: What|Removed |Added Status|NEW |ASSIGNED Keywords||ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org --- Comment #1 from Kewen Lin --- Thanks for reporting! Confirmed.
[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 --- Comment #15 from Kewen Lin --- (In reply to Arseny Solokha from comment #14) > W/ gcc 13.0.0 20221225 snapshot (g:febb58d28bfa4b544ec7ffec2d61f46d25205ff0) > I still get this ICE when compiling > gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c: > Thanks for reporting, confirmed. The function rs6000_opaque_type_invalid_use_p only handles gassign, this failure shows another usage with asm, so we need to teach about gasm. Since it's for a new usage, I think it's better to have one separated bug for it. Do you mind to file a new one? Btw, excepting for this kind of asm usage, do you spot some others?
[Bug c/108271] New: Missed RVV cost model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108271
Bug ID: 108271
Summary: Missed RVV cost model
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
#include "riscv_vector.h"
void f3 (int * restrict in, int * restrict out, void * restrict mask_in, int n)
{
vfloat32mf2_t v = __riscv_vle32_v_f32mf2 ((float *)(in + 1), 19);
__riscv_vse32_v_f32mf2 ((float *)(out + 1), v, 19);
vbool64_t mask = *(vbool64_t*)mask_in;
for (int i = 0; i < n; i++)
{
vint16mf2_t v1 = __riscv_vle16_v_i16mf2 ((int16_t *)(in + i + 1), 19);
__riscv_vse16_v_i16mf2 ((int16_t *)(out + i + 1), v1, 19);
vint32mf2_t v2 = __riscv_vle32_v_i32mf2 ((int32_t *)(in + i + 2), 19);
__riscv_vse32_v_i32mf2 ((int32_t *)(out + i + 2), v2, 19);
vint32mf2_t v3 = __riscv_vle32_v_i32mf2_tumu (mask, v2, (int32_t *)(in +
i + 200), 13);
*(vint32mf2_t*)(out + i + 200) = v3;
vfloat64m1_t v4 = __riscv_vle64_v_f64m1_m (mask, (double *)(in + i +
300), 11);
__riscv_vse64_v_f64m1 ((double *)(out + i + 300), v4, 11);
vfloat64m1_t v5 = __riscv_vle64_v_f64m1_tum (mask, v4, (double *)(in + i
+ 500), 11);
__riscv_vse64_v_f64m1 ((double *)(out + i + 500), v5, 11);
vfloat64m1_t v6 = __riscv_vle64_v_f64m1_mu (mask, v5, (double *)(in + i +
600), 11);
__riscv_vse64_v_f64m1_m (mask, (double *)(out + i + 600), v6, 11);
vuint8mf4_t v7 = __riscv_vle8_v_u8mf4 ((uint8_t *)(in + i + 700), 11);
__riscv_vse8_v_u8mf4 ((uint8_t *)(out + i + 700), v7, 11);
vuint8mf4_t v8 = __riscv_vle8_v_u8mf4 ((uint8_t *)(in + i + 800), 11);
__riscv_vse8_v_u8mf4 ((uint8_t *)(out + i + 800), v7, 11);
vuint8mf4_t v9 = __riscv_vle8_v_u8mf4 ((uint8_t *)(in + i + 900), 11);
__riscv_vse8_v_u8mf4 ((uint8_t *)(out + i + 900), v7, 11);
vuint8mf4_t v10 = __riscv_vle8_v_u8mf4 ((uint8_t *)(in + i + 1000), 11);
__riscv_vse8_v_u8mf4 ((uint8_t *)(out + i + 1000), v7, 11);
}
}
-O3 -S ASM:
f3:
li a5,40960
addia5,a5,-960
addisp,sp,-64
sd s4,24(sp)
add a4,a0,a5
add a5,a1,a5
vsetivlizero,19,e32,mf2,ta,ma
vle32.v v24,0(a4)
vse32.v v24,0(a5)
vsetvli s4,zero,e8,mf8,ta,ma
vlm.v v0,0(a2)
ble a3,zero,.L1
addia3,a3,1
sd s3,32(sp)
sllia3,a3,2
li s3,4096
sd s2,40(sp)
sd s5,16(sp)
sd s6,8(sp)
addit6,s3,-1700
addit5,s3,-1300
addis6,s3,-900
addis5,s3,-500
sd s0,56(sp)
sd s1,48(sp)
addia0,a0,4
addia4,a1,4
add s2,a1,a3
addis3,s3,-100
.L3:
vsetivlizero,19,e16,mf2,ta,ma
mv a5,a4
vle16.v v24,0(a0)
mv a3,a0
vse16.v v24,0(a4)
addia0,a0,4
vsetivlizero,19,e32,mf2,ta,ma
addia4,a4,4
vle32.v v24,0(a0)
addis1,a3,796
vse32.v v24,0(a4)
vsetivlizero,13,e32,mf2,tu,mu
addis0,a5,796
vle32.v v24,0(s1),v0.t
addia1,a3,1196
addit4,a5,1196
addit2,a3,1996
addit3,a5,1996
add t0,a3,t6
vsetvli s4,zero,e32,mf2,ta,ma
add t1,a5,t6
vse32.v v24,0(s0)
add a7,a5,t5
vsetivlizero,11,e64,m1,tu,mu
add a6,a5,s6
vle64.v v24,0(a1),v0.t
add a2,a5,s5
vse64.v v24,0(t4)
add a3,a3,t5
vle64.v v24,0(t2),v0.t
add a5,a5,s3
vse64.v v24,0(t3)
vle64.v v24,0(t0),v0.t
vse64.v v24,0(t1),v0.t
vsetivlizero,11,e8,mf4,ta,ma
vle8.v v24,0(a3)
vse8.v v24,0(a7)
vse8.v v24,0(a6)
vse8.v v24,0(a2)
vse8.v v24,0(a5)
bne s2,a4,.L3
ld s0,56(sp)
ld s1,48(sp)
ld s2,40(sp)
ld s3,32(sp)
ld s5,16(sp)
ld s6,8(sp)
.L1:
ld s4,24(sp)
addisp,sp,64
jr ra
GCC allocate redundant stack and generate a lot of redundant ld or sd
instructions.
However, if we use -O3 -fno-schedule-insns ASM:
f3:
li a5,40960
addia5,a5,-960
add a4,a0,a5
add a5,a1,a5
vsetivlizero,19,e32,mf2,ta,ma
vle32.v v24,0(a4)
vse32.v v24,0(a5)
vsetvli t3,zero,e8,mf8,ta,ma
vlm.v v0,0(a2)
ble a3,zero,.L1
addia3,a3,1
li t1,4096
sllia3,a3,2
addia4,a1,4
addia7,t1,-1700
addia6,t1,-1300
[Bug target/108271] Missed RVV cost model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108271 --- Comment #1 from Andrew Pinski --- More likely there should be a generic scheduling model that handles RVV too instead of a cost issue ...
[Bug target/108271] Missed RVV cost model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108271 --- Comment #2 from JuzheZhong --- (In reply to Andrew Pinski from comment #1) > More likely there should be a generic scheduling model that handles RVV too > instead of a cost issue ... OK. This issue should be fixed after I support all RVV intrinsics.
[Bug target/108185] [RISC-V] Sub-optimal code-gen for vsetvli: redundant stack store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185 Kito Cheng changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-01-03 --- Comment #4 from Kito Cheng --- So it's about the code gen quality instead of correctness, let me update the title.
[Bug target/108272] New: [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:339
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108272
Bug ID: 108272
Summary: [13 Regression] ICE in gen_movxo, at
config/rs6000/mma.md:339
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: linkw at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-*-linux-gnu
This issue was originally reported in PR106736 comment 14.
gcc 13.0.0 20221225 snapshot (g:febb58d28bfa4b544ec7ffec2d61f46d25205ff0) ICEs
when compiling gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c:
% powerpc-e300c3-linux-gnu-gcc-13 -c
gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c
gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c: In function 'foo1':
gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c:20:10: warning: GCC vector
returned by reference: non-standard ABI extension with no compatibility
guarantee [-Wpsabi]
20 | vec[1] = __builtin_vsx_xvcvspbf16 (vec[0]);
| ~~~^~~
during RTL pass: expand
gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c: In function 'foo0':
gcc/testsuite/gcc.target/powerpc/mma-builtin-3.c:9:3: internal compiler error:
in gen_movxo, at config/rs6000/mma.md:339
9 | asm ("#..." : "=d" (acc));
| ^~~
0x780433 gen_movxo(rtx_def*, rtx_def*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/config/rs6000/mma.md:339
0xa767b7 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/recog.h:407
0xa767b7 emit_move_insn_1(rtx_def*, rtx_def*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/expr.cc:4172
0xa76bbf emit_move_insn(rtx_def*, rtx_def*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/expr.cc:4342
0xa7ef4e store_expr(tree_node*, rtx_def*, int, bool, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/expr.cc:6519
0xa81703 expand_assignment(tree_node*, tree_node*, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/expr.cc:6051
0x9479f7 expand_asm_stmt
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/cfgexpand.cc:3345
0x94bd29 expand_gimple_stmt_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/cfgexpand.cc:3877
0x94bd29 expand_gimple_stmt
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/cfgexpand.cc:4044
0x951d4e expand_gimple_basic_block
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/cfgexpand.cc:6096
0x953866 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/cfgexpand.cc:6822
[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 --- Comment #16 from Arseny Solokha --- (In reply to Kewen Lin from comment #15) > Thanks for reporting, confirmed. The function > rs6000_opaque_type_invalid_use_p only handles gassign, this failure shows > another usage with asm, so we need to teach about gasm. Since it's for a new > usage, I think it's better to have one separated bug for it. Do you mind to > file a new one? Sure, I've just filed PR108272. > Btw, excepting for this kind of asm usage, do you spot some others? Not yet. Due to the way my test setup works, I don't distinguish different causes of the same ICE. I'll try to collect more cases by the end of the week.
[Bug target/108240] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #2 from Kewen Lin ---
Well, there are two issues here:
1) the ICE itself, it's independent of option powerpc64 handling, without the
culprit commit r13-4894 but with an explicit option -m64, the ICE is still
reproducible. So this exposes one latent bug.
When specifying -mcpu=401, it uses the default flag OPTION_MASK_SOFT_FLOAT
(soft-float), it means there is no hard-float support. But specifying the
undocumented option -mmodulo, it means to act like power9 (setting all ISA3.0
flags excepting for some -mno-xxx) as the code:
if (TARGET_P9_VECTOR || TARGET_MODULO || TARGET_P9_MISC)
rs6000_isa_flags |= (ISA_3_0_MASKS_SERVER & ~ignore_masks);
It results in one unexpected state that we don't have hard-float support but we
still have P9 vector supports (of coz. VSX). Later when expanding SFmode smul,
it tries to use wider mode KFmode for the multiplication then ICE.
Currently we have some checks on the co-existence between TARGET_VSX and
!TARGET_HARD_FLOAT, I think we also need to extend it to cover those options
which can enable VSX later:
if (TARGET_P9_VECTOR || TARGET_MODULO || TARGET_P9_MISC)
rs6000_isa_flags |= (ISA_3_0_MASKS_SERVER & ~ignore_masks);
else if (TARGET_P9_MINMAX)
{
...
else
rs6000_isa_flags |= ISA_3_0_MASKS_SERVER;
}
else if (TARGET_P8_VECTOR || TARGET_DIRECT_MOVE || TARGET_CRYPTO)
rs6000_isa_flags |= (ISA_2_7_MASKS_SERVER & ~ignore_masks);
else if (TARGET_VSX)
rs6000_isa_flags |= (ISA_2_6_MASKS_SERVER & ~ignore_masks);
If we have !TARGET_HARD_FLOAT and any of TARGET_P9_VECTOR, TARGET_MODULO,
TARGET_P9_MISC, TARGET_P9_MINMAX, TARGET_P8_VECTOR, TARGET_DIRECT_MOVE,
TARGET_CRYPTO, we are pretending there is one explicit -mno-vsx:
rs6000_isa_flags &= ~ OPTION_MASK_VSX;
rs6000_isa_flags_explicit |= OPTION_MASK_VSX;
[Bug target/108240] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 Kewen Lin changed: What|Removed |Added Target|poiwerpc|powerpc CC||bergner at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #3 from Kewen Lin --- 2) before the culprit commit r13-4894, if there is an explicit -m64, it does set powerpc64 (as it's set explicitly), while if there is no explicit -m64, it does nothing. The implicit 64 bit setting would always implicitly enable powerpc64 initially, so it's fine. As this case shows, it's possible that the used cpu would unset powerpc64 later if it's not default. With the culprit commit r13-4894, we always implicitly enable powerpc64 for both explicit and implicit 64 bit, it's the same as before for the explicit 64 bit case, but for the implicit 64 bit case, there is no chance for the used cpu to unset powerpc64 (like this case). To keep it consistent with the previous, the fix can be to only enable powerpc64 implicitly for explicit 64 bit, while let it be for implicit 64 bit.
[Bug target/108272] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:339
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108272 Kewen Lin changed: What|Removed |Added Last reconfirmed||2023-01-03 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Target Milestone|--- |13.0 --- Comment #1 from Kewen Lin --- Confirmed! Thanks for reporting! Need to teach function rs6000_opaque_type_invalid_use_p about gasm, as the failed case shows, there is this kind of actual test case to use opaque type in inline asm statement.
[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 --- Comment #17 from Kewen Lin --- (In reply to Arseny Solokha from comment #16) > (In reply to Kewen Lin from comment #15) > > Thanks for reporting, confirmed. The function > > rs6000_opaque_type_invalid_use_p only handles gassign, this failure shows > > another usage with asm, so we need to teach about gasm. Since it's for a new > > usage, I think it's better to have one separated bug for it. Do you mind to > > file a new one? > > Sure, I've just filed PR108272. Got it, thanks! > > > Btw, excepting for this kind of asm usage, do you spot some others? > > Not yet. Due to the way my test setup works, I don't distinguish different > causes of the same ICE. I'll try to collect more cases by the end of the > week. Many thanks!
