[Bug tree-optimization/106099] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099 --- Comment #12 from Martin Liška --- @Jakub: Can you please take a look at the new testcase that still ICEs?
[Bug tree-optimization/106099] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099
--- Comment #13 from Martin Liška ---
One another testcase:
$ gcc /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/pr63839.c
-Og
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/pr63839.c: In
function ‘bar’:
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/pr63839.c:9:1:
warning: ‘noreturn’ function does return
9 | } /* { dg-warning "function does return" } */
| ^
during GIMPLE pass: local-pure-const
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/pr63839.c:21:1:
internal compiler error: in execute_todo, at passes.cc:2140
21 | }
| ^
0x76e8ac execute_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2140
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/106679] [13 regression] gcc.dg/tree-prof/cmpsf-1.c fails after r13-2098-g5adfb6540db95d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106679 Aldy Hernandez changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #3 from Aldy Hernandez --- (In reply to seurer from comment #0) > g:5adfb6540db95da5faf1f77fbe9ec38b4cf8eb1f, r13-2098-g5adfb6540db95d > make -k check-gcc RUNTESTFLAGS="tree-prof.exp=gcc.dg/tree-prof/cmpsf-1.c" > FAIL: gcc.dg/tree-prof/cmpsf-1.c scan-tree-dump-not dom2 "Invalid sum" > # of expected passes 4 > # of unexpected failures 1 > # of unsupported tests1 > > commit 5adfb6540db95da5faf1f77fbe9ec38b4cf8eb1f (HEAD, refs/bisect/bad) > Author: Aldy Hernandez > Date: Wed Aug 17 17:47:21 2022 +0200 > > Reset root oracle from path_oracle::reset_path. Before this patch, we nuked the path sensitive relational oracle when we crossed a backedge, causing us to be dumber on subsequent requests from the path solver. With the patch in place, we're threading more paths earlier (threadfull1 instead of DOM2), which presumably is messing up the probabilities. The generic BB copier the backward threader uses is known to not keep good track of probabilities. It is a known limitation, and there is at least one PR (??) open for this. The reason we're seeing this now is two fold: first, because we're no longer destroying the path oracle, and second because ranger now handles floats which this test stresses. Perhaps we could add -fdisable-tree-threadfull1 to the test, since it was originally testing changes in DOM threading.
[Bug middle-end/106662] [OpenMP] 'for simd firstprivate(j) lastprivate(j)' with 'parallel shared(j)' gives unexpected result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106662 --- Comment #2 from Jakub Jelinek --- As I wrote on omp-lang, I believe this is UB. simd doesn't accept firstprivate clause, but does accept lastprivate. So, each SIMD lane's private j starts uninitialized (or for C++ default constructed but for int that is the same thing) and the value from the SIMD lane corresponding to last iteration is copied over to the private copy of j in the worksharing-loop. With simd, one has basically these data-sharing possibilities: 1) no data sharing clause, then it works kind like "shared", all SIMD lanes read the same variable, they'd better not to store it as that would be a data race 2) private - each SIMD lane has its private copy of the var, uninitialized/default-constructed at the start, destroyed at the end 3) lastprivate - likewise, but before it is destroyed, the SIMD lane corresponding to last iteration copies to original var 4) linear - must be integral, each SIMD lane gets the private var initialized with the original list value + step * SIMD_lane_# and the last iteration effect like lastprivate
[Bug c++/106713] [11/12/13 Regression] Coroutine regression in GCC 11.3.0: if (co_await ...) crashes with a jump to ud2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106713 Richard Biener changed: What|Removed |Added CC||iains at gcc dot gnu.org Summary|Coroutine regression in GCC |[11/12/13 Regression] |11.3.0: if (co_await ...) |Coroutine regression in GCC |crashes with a jump to ud2 |11.3.0: if (co_await ...) ||crashes with a jump to ud2 Target Milestone|--- |11.4 Known to work||11.2.0 Known to fail||11.3.0, 12.2.0, 13.0 Keywords||wrong-code
[Bug ipa/106716] Identical Code Folding (-fipa-icf) confuses between functions with different [[likely]] attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106716 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-08-23 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||missed-optimization --- Comment #4 from Richard Biener --- Confirmed.
[Bug tree-optimization/106717] [13 Regression] ICE: tree check: expected integer_cst, have poly_int_cst in get_len, at tree.h:6247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106717 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 Keywords||needs-bisection
[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558 --- Comment #11 from Yuri Gribov --- Created attachment 53493 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53493&action=edit Updated patch Here is an updated patch which passes bootstrap-asan (I haven't run the testsuite yet). It results in only small 0.15% reduction of optimized checks (146062 -> 145824). But more importantly the complicated alias oracle check does not seem to contribute anything - removing it from same_value_p function (the name is ugly, I know) does not change the number of optimized checks. So I'm not sure it makes sense to keep it in final patch.
[Bug middle-end/106662] [OpenMP] 'for simd firstprivate(j) lastprivate(j)' with 'parallel shared(j)' gives unexpected result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106662 --- Comment #3 from Jakub Jelinek --- So, if you want to make the testcase working after changing for to for simd, one would need to use 2 variables instead of 1, one that is firstprivate and one that is lastprivate, and just j = k + i; if k is firstprivate and j is lastprivate.
[Bug libgcc/106720] New: gcc does not compile with XCode 13.4.1 / clang 13.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106720 Bug ID: 106720 Summary: gcc does not compile with XCode 13.4.1 / clang 13.1.6 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Trying to compile the full gcc on Darwin x86_64 (not M1, darwin-arm64, not checked yet), the gcc 13.0.0 (git clone as of today) fails to compile with the following error message: ../../libcpp/include/cpplib.h:292:3: error: "Cannot find a least-32-bit signed integer type" # error "Cannot find a least-32-bit signed integer type" ^ ../../libcpp/include/cpplib.h:294:34: error: expected ';' after top level declarator typedef unsigned CPPCHAR_SIGNED_T cppchar_t; ^ ; ../../libcpp/include/cpplib.h:1163:8: error: unknown type name 'cppchar_t'; did you mean 'wchar_t'? extern cppchar_t cpp_interpret_charconst (cpp_reader *, const cpp_token *, ^ wchar_t ../../libcpp/include/cpplib.h:1180:8: error: unknown type name 'cppchar_t'; did you mean 'wchar_t'? extern cppchar_t cpp_host_to_exec_charset (cpp_reader *, cppchar_t); ^ wchar_t ../../libcpp/include/cpplib.h:1180:58: error: unknown type name 'cppchar_t'; did you mean 'wchar_t'? extern cppchar_t cpp_host_to_exec_charset (cpp_reader *, cppchar_t); ^ wchar_t ../../libcpp/include/cpplib.h:1361:8: error: unknown type name 'cppchar_t'; did you mean 'wchar_t'? extern cppchar_t cpp_parse_escape (cpp_reader *, const unsigned char ** pstr, ^ wchar_t ../../libcpp/include/cpplib.h:1492:3: error: unknown type name 'cppchar_t'; did you mean 'wchar_t'? cppchar_t m_ch;
[Bug bootstrap/106720] gcc does not compile with XCode 13.4.1 / clang 13.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106720 Jakub Jelinek changed: What|Removed |Added Component|libgcc |bootstrap CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- While compiling which file? Is SIZEOF_INT and SIZEOF_LONG correctly defined in libcpp/config.h ? Perhaps CHAR_BIT isn't defined? Usually libcpp/ sources include "system.h" before including "cpplib.h" and system.h has: #if HAVE_LIMITS_H # include #endif and so CHAR_BIT should be defined unless limits.h isn't present. The cpplib.h part is: #if CHAR_BIT * SIZEOF_INT >= 32 # define CPPCHAR_SIGNED_T int #elif CHAR_BIT * SIZEOF_LONG >= 32 # define CPPCHAR_SIGNED_T long #else # error "Cannot find a least-32-bit signed integer type" #endif
[Bug target/106721] New: Error: invalid character '<' in mnemonic since r13-2122-g86c0d98620ee3a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106721
Bug ID: 106721
Summary: Error: invalid character '<' in mnemonic since
r13-2122-g86c0d98620ee3a
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: haochen.jiang at intel dot com
Target Milestone: ---
The following assembler error is reported:
$ cat bf16.i
typedef __bf16 __m256bf16 __attribute__((__vector_size__(32)));
int snapshot;
__m256bf16 fregs_6_0_0;
volatile __bf16 bf9, bf10, bf11, bf12, bf13, bf14, bf15;
void fun_check_passing_m256bf16_8_regs();
void test_m256bf16_on_stack() {
__m256bf16 x[8];
int i = 0;
for (; i < 8; i++)
x[i] = (__m256bf16){bf9, bf10, bf11, bf12, bf13, bf14, bf15};
fregs_6_0_0 = x[6];
((typeof(&fun_check_passing_m256bf16_8_regs))snapshot)(x[0], x[6], x[7]);
}
$ gcc bf16.i -c -march=skylake-avx512 -w -Ofast --save-temps
bf16.s: Assembler messages:
bf16.s:88: Error: invalid character '<' in mnemonic
bf16.s:93: Error: invalid character '<' in mnemonic
bf16.s:94: Error: invalid character '<' in mnemonic
$ cat -n bf16.s
...
88 vinsert32x4$0x1, %xmm16, %ymm1, %ymm1
...
[Bug target/106721] Error: invalid character '<' in mnemonic since r13-2122-g86c0d98620ee3a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106721 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-08-23 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||hjl at gcc dot gnu.org
[Bug bootstrap/106720] gcc does not compile with XCode 13.4.1 / clang 13.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106720 --- Comment #2 from Jürgen Reuter --- Hi Jakub, this is the compilation command: g++ -std=c++11 -I../../libcpp -I. -I../../libcpp/../include -I./../intl -I../../libcpp/include -g -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -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 In file included from ../../libcpp/charset.cc:22: This is the limits.h from XCode // -*- C++ -*- //===--- limits.h -===// // // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. // See https://llvm.org/LICENSE.txt for license information. // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception // //===--===// #ifndef _LIBCPP_LIMITS_H #define _LIBCPP_LIMITS_H /* limits.h synopsis Macros: CHAR_BIT SCHAR_MIN SCHAR_MAX UCHAR_MAX CHAR_MIN CHAR_MAX MB_LEN_MAX SHRT_MIN SHRT_MAX USHRT_MAX INT_MIN INT_MAX UINT_MAX LONG_MIN LONG_MAX ULONG_MAX LLONG_MIN // C99 LLONG_MAX // C99 ULLONG_MAX // C99 */ #include <__config> #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER) #pragma GCC system_header #endif #ifndef __GNUC__ #include_next #else // GCC header limits.h recursively includes itself through another header called // syslimits.h for some reason. This setup breaks down if we directly // #include_next GCC's limits.h (reasons not entirely clear to me). Therefore, // we manually re-create the necessary include sequence below: // Get the system limits.h defines (force recurse into the next level) #define _GCC_LIMITS_H_ #define _GCC_NEXT_LIMITS_H #include_next // Get the ISO C defines #undef _GCC_LIMITS_H_ #include_next #endif // __GNUC__ #endif // _LIBCPP_LIMITS_H
[Bug target/106721] Error: invalid character '<' in mnemonic since r13-2122-g86c0d98620ee3a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106721
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Slightly cleaned up testcase:
typedef __bf16 __m256bf16 __attribute__((__vector_size__(32)));
void (*bar) (__m256bf16, __m256bf16, __m256bf16);
__m256bf16 a;
volatile __bf16 b, c, d, e, f, g, h;
void
foo (void)
{
__m256bf16 x[8];
int i;
for (i = 0; i < 8; i++)
x[i] = (__m256bf16) { b, c, d, e, f, g, h };
a = x[6];
bar (x[0], x[6], x[7]);
}
[Bug tree-optimization/106722] New: bogus uninit warning in tree-vect-loop-manip.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106722
Bug ID: 106722
Summary: bogus uninit warning in tree-vect-loop-manip.cc
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
The following is a reduced testcase for the bogus uninit warning during
bootstrap on riscv.
Warns with -O2 -Wmaybe-uninitialized --param logical-op-non-short-circuit=0
long pow2p_hwi_x;
bool exact_log2___trans_tmp_5, exact_log2___trans_tmp_4;
int exact_log2(long x) {
exact_log2___trans_tmp_5 = pow2p_hwi_x && exact_log2___trans_tmp_4;
return exact_log2___trans_tmp_5 ? x : 1;
}
enum signop {};
template void rshift(T1, T2, signop);
struct generic_wide_int {
template generic_wide_int(T);
};
template struct poly_int_pod {
bool is_constant() const;
template bool is_constant(T *) const;
int coeffs[N];
};
template
template
bool poly_int_pod::is_constant(T *const_value) const {
if (is_constant()) {
*const_value = coeffs[0];
return true;
}
return false;
}
struct poly_int : poly_int_pod<1, int> {
template poly_int(C0);
};
enum tree_code_class {} tree_code_type;
void tree_class_check_failed(int *, tree_code_class, char *, int, char *)
__attribute__((__noreturn__));
int tree_class_check___t, tree_class_check___l,
vect_gen_vector_loop_niters_loop_vinfo;
char tree_class_check___f, tree_class_check___g;
tree_code_class tree_class_check___class;
int *tree_class_check() {
if (tree_code_type)
tree_class_check_failed(&tree_class_check___t, tree_class_check___class,
&tree_class_check___f, tree_class_check___l,
&tree_class_check___g);
return &tree_class_check___t;
}
int *build_int_cst(int, long);
bool is_gimple_val(int);
void force_gimple_operand(int, int *, bool, int);
void vect_gen_vector_loop_niters(bool niters_no_overflow) {
poly_int vf(vect_gen_vector_loop_niters_loop_vinfo);
int *log_vf = nullptr;
long const_vf;
if (vf.is_constant(&const_vf))
log_vf = build_int_cst(0, 0);
if (is_gimple_val(0)) {
int stmts;
force_gimple_operand(0, &stmts, true, 0);
if (stmts && log_vf)
if (niters_no_overflow) {
generic_wide_int __trans_tmp_1(tree_class_check());
int __trans_tmp_2 = exact_log2(const_vf);
rshift(__trans_tmp_1, __trans_tmp_2, (signop)0);
}
}
}
[Bug target/106721] Error: invalid character '<' in mnemonic since r13-2122-g86c0d98620ee3a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106721 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Looking now at tmp-mddump.md for all problematic cases.
[Bug tree-optimization/106722] bogus uninit warning in tree-vect-loop-manip.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106722 --- Comment #1 from Richard Biener --- The uninit code already handles this but it runs into its MAX_CHAIN_LEN path discovery limit. upping that by one fixes the reduced testcase, upping it to 8 (from 5) fixes original preprocessed source.
[Bug tree-optimization/106722] bogus uninit warning in tree-vect-loop-manip.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106722 --- Comment #2 from Richard Biener --- Note it's the dependence chain from def to use that is empty because of this limit.
[Bug target/106721] Error: invalid character '<' in mnemonic since r13-2122-g86c0d98620ee3a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106721 --- Comment #3 from Jakub Jelinek --- Created attachment 53494 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53494&action=edit gcc13-pr106721.patch Untested fix. This fixes all <[a-zA-Z] occurrences in tmp-mddump.md (except those in comments). Whether for V*BF or V*HF modes it is better to use i or f suffixed broadcast etc. is something I have no idea about, used f for now.
[Bug middle-end/106548] [OpenMP] ICE in #pragma openmp parallel for simd linear with long long variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106548 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:2413eed009878c347c65950c649c0da59e759238 commit r12-8703-g2413eed009878c347c65950c649c0da59e759238 Author: Tobias Burnus Date: Wed Aug 17 15:45:56 2022 +0200 OpenMP: Fix var replacement with 'simd' and linear-step vars [PR106548] gcc/ChangeLog: PR middle-end/106548 * omp-low.cc (lower_rec_input_clauses): Use build_outer_var_ref for 'simd' linear-step values that are variable. libgomp/ChangeLog: PR middle-end/106548 * testsuite/libgomp.c/linear-2.c: New test. (cherry picked from commit d9c9424d2c4f7b25acfc00db0076a65882c8a99f)
[Bug fortran/106566] [OpenMP] declare simd fails with with bogus "already been host associated" for module procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106566 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:50b7cf395656ccd32d4d5d8e0e338135d28f52f6 commit r12-8704-g50b7cf395656ccd32d4d5d8e0e338135d28f52f6 Author: Tobias Burnus Date: Tue Aug 23 11:29:23 2022 +0200 Fortran: OpenMP fix declare simd inside modules and absent linear step [PR106566] Partial backport from commit r13-2093, only, as 'OpenMP 5.2 linear clause syntax' is not on GCC 12. gcc/fortran/ChangeLog: PR fortran/106566 * openmp.cc (gfc_match_omp_declare_simd): Accept module procedures. gcc/testsuite/ChangeLog: PR fortran/106566 * gfortran.dg/gomp/declare-simd-6.f90: New test. (cherry picked from commit 1513512ec7d0751cba30c9c8804f2be462acfb9b)
[Bug debug/106719] [10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2 since r10-6038-ge5e07b68187b9a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106719 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-08-23 Summary|'-fcompare-debug' failure |[10/11/12/13 Regression] |w/ -O2 |'-fcompare-debug' failure ||w/ -O2 since ||r10-6038-ge5e07b68187b9a CC||marxin at gcc dot gnu.org, ||wdijkstr at arm dot com Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r10-6038-ge5e07b68187b9a.
[Bug bootstrap/106720] gcc does not compile with XCode 13.4.1 / clang 13.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106720 Jürgen Reuter changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jürgen Reuter --- Sorry, my mistake that I already made before: I had a non-vanishing C_/CPLUS_INCLUDE_PATH in my local variables which picked up a gcc, i.e. not the proper clang include files. Mea culpa.
[Bug c++/106713] [11/12/13 Regression] Coroutine regression in GCC 11.3.0: if (co_await ...) crashes with a jump to ud2 since r12-3529-g70ee703c479081ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106713 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-08-23 Status|UNCONFIRMED |NEW Summary|[11/12/13 Regression] |[11/12/13 Regression] |Coroutine regression in GCC |Coroutine regression in GCC |11.3.0: if (co_await ...) |11.3.0: if (co_await ...) |crashes with a jump to ud2 |crashes with a jump to ud2 ||since ||r12-3529-g70ee703c479081ac CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Started with r12-3529-g70ee703c479081ac (or the revision before - I can't build it).
[Bug tree-optimization/106722] bogus uninit warning in tree-vect-loop-manip.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106722 --- Comment #3 from Richard Biener --- Created attachment 53495 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53495&action=edit preprocessed source, from riscv This is the original preprocessed testcase from riscv64-linux. Reproduces with a cc1plus with -O2 -Wuninitialized -march=rv64imafdc_zicsr_zifencei -mabi=lp64d
[Bug tree-optimization/106099] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099 --- Comment #14 from Jakub Jelinek --- Created attachment 53496 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53496&action=edit gcc13-pr106099.patch Untested fix. There are 2 issues. One was that tree-cfg.cc was emitting __builtin_trap instead of __builtin_unreachable which needed vops (fixed by emitting .TRAP instead) and another one was that CDDCE was actually throwing away .TRAP calls - since PR44485 flags_from_decl_or_type actually implicitly adds ECF_LOOPING_CONST_OR_PURE to ECF_NORETURN|ECF_CONST normal calls, so __builtin_unreachable wasn't DCEd even when it is const and lhs was NULL, but for internal-fns that doesn't happen, so I had to add ECF_LOOPING_CONST_OR_PURE explicitly to avoid DCE of .TRAP.
[Bug target/106723] New: Unreplaced mode/code attributes in aarch64/arm backends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106723
Bug ID: 106723
Summary: Unreplaced mode/code attributes in aarch64/arm
backends
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: ---
Following command (run after seeing PR106721 on x86) shows on aarch64-linux:
make mddump; grep '<[a-zA-Z]' tmp-mddump.md
return "fcmla\t%0.2d, %2.2d, %3., #0";
return "fcmla\t%0.2d, %2.2d, %3., #90";
return "fcmla\t%0.2d, %2.2d, %3., #180";
return "fcmla\t%0.2d, %2.2d, %3., #270";
Similar command on armhfp-linux-gnueabi:
grep '<[a-zA-Z]' tmp-mddump.md
return "vldr.64\t%q0, %E1";
return "vstr.64\t%q1, %E0";
return "vldr.\t%q0, %E1";
return "vstr.\t%q1, %E0";
return "vldr.\t%q0, %E1";
return "vstr.\t%q1, %E0";
] ("TARGET_HAVE_MVE || TARGET_HAVE_MVE_FLOAT") ("vdup.\t%q0,
%1")
I admit I haven't looked into details of any of this, but it looks like
mode attributes that weren't replaced.
[Bug tree-optimization/106722] bogus uninit warning in tree-vect-loop-manip.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106722 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:baa3ffb19c54fa334ac2884f6acb5d31aa79ac32 commit r13-2155-gbaa3ffb19c54fa334ac2884f6acb5d31aa79ac32 Author: Richard Biener Date: Tue Aug 23 13:58:31 2022 +0200 tree-optimization/106722 - uninit analysis with long def -> use path The following applies similar measures as r13-2133-ge66cf626c72d58 to the computation of the use predicate when the path from PHI def to use is too long and we run into compute_control_dep_chain limits. It also moves the preprocessor define limits internal. This resolves the reduced testcase but not the original one. PR tree-optimization/106722 * gimple-predicate-analysis.h (MAX_NUM_CHAINS, MAX_CHAIN_LEN, MAX_POSTDOM_CHECK, MAX_SWITCH_CASES): Move ... * gimple-predicate-analysis.cc: ... here and document. (simple_control_dep_chain): New function, factored from predicate::use_cannot_happen. (predicate::use_cannot_happen): Adjust. (predicate::predicate): Use simple_control_dep_chain as fallback. * g++.dg/uninit-pr106722-1.C: New testcase.
[Bug tree-optimization/106722] bogus uninit warning in tree-vect-loop-manip.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106722
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2022-08-23
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #5 from Richard Biener ---
Applying
--- t.ii2022-08-23 12:53:55.066853095 +0200
+++ t2.ii 2022-08-23 15:08:16.699682010 +0200
@@ -1,7 +1,6 @@
-long pow2p_hwi_x;
bool exact_log2___trans_tmp_5, exact_log2___trans_tmp_4;
int exact_log2(long x) {
- exact_log2___trans_tmp_5 = pow2p_hwi_x && exact_log2___trans_tmp_4;
+ exact_log2___trans_tmp_5 = x && exact_log2___trans_tmp_4;
return exact_log2___trans_tmp_5 ? x : 1;
}
enum signop {};
to the testcase makes it still fail.
[Bug debug/106718] GCC does not follow DWARF5 standard for DW_AT_ranges and DW_FORM_rnglistx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106718 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I don't see anything wrong. DW_AT_ranges in DW_TAG_skeleton_unit in .debug_info section uses DW_FORM_sec_offset and refers to .debug_rnglists section which has .long 0 # Offset Entry Count Then DW_AT_ranges in DW_TAG_inlined_subroutine (twice) and in DW_TAG_lexical_block all in .debug_info.dwo section use DW_FORM_rnglistx, but those don't refer to .debug_rnglists section, but to .debug_rnglists.dwo section, which has: .long 0x2 # Offset Entry Count .Ldebug_ranges1: .long .LLRL5-.Ldebug_ranges1 .long .LLRL9-.Ldebug_ranges1 Just look at DWARF5 Appendix B. Debug Section Relationships (Informative) graph, it is the (io) link in there.
[Bug fortran/106692] [10/11/12/13 Regression] Cray pointer comparison wrongly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- Pre-remark: As Cray pointers are outside the spec, it is a bit difficult to know what to expect. – I do note that it compiles fine with ifort + optimizations turned on, whatever that means. This and that it did work with GCC and this PR exists implies that there is real-world code out there which now fails - but worked before. (Independent whether the code is valid or not.) * * * Regarding the code, given that subroutine shape_cray(zz1) ! REAL :: zz1 ! (implicitly typed) is a normal variable, I would expect from normal Fortran rules that it is definable – and, hence, can not be a NULL pointer. If I wanted to pass a Cray pointer, I would make the dummy argument a Cray pointer – namely, passing a pointer - and not the pointee: subroutine shape_cray(ptrzz1) ! << changed to ptrzz1 from zz1 for better naming pointer(ptrzz1 , zz1) ! << added line - ptrzz1 is now a cray pointer pointer(ptrzz, zz) Accordingly, the callee then has to use: call shape_cray(ptrzz1) ! pass the pointer instead of call shape_cray(zz1) This also passes by reference (-fdump-tree-original): void shape_cray (integer(kind=8) & restrict ptrzz1) but that's the pointer (which must be present) but not the pointee. When passing the Cray pointer, everything seems to work fine and looks well defined. * * * In my humble opinion, passing a Cray pointer and using a Cray-pointer dummy argument is the proper Cray-pointer way. Regarding OPTIONAL - that would work as well, but means the the interface has to be availble at the callee side, i.e. either an 'interface' block or shape_cray needs to be contained in a module or in the caller - or it and the caller need to be contained in the same subprogram (like contained in the 'program'). All of that is fine, but wasn't available in Fortran 77 - the time Cray pointers were invented.
[Bug driver/81358] libatomic not automatically linked with C11 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 --- Comment #13 from Jeffrey Walton --- Add a mee too. When using sanitizers, like -fsanitize=undefined, the compiler driver is not adding the necessary libraries to link the program. Ugh... https://github.com/weidai11/cryptopp/issues/1141#issuecomment-1224069820
[Bug target/106714] Incorrect casts in macros in amxtileintrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106714 --- Comment #1 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:aeb9b58225916bc84a0cd02c6fc77bbb92167e53 commit r13-2156-gaeb9b58225916bc84a0cd02c6fc77bbb92167e53 Author: H.J. Lu Date: Thu Aug 18 14:17:33 2022 -0700 x86: Cast stride to __PTRDIFF_TYPE__ in AMX intrinsics On 64-bit Windows, long is 32 bits and can't be used as stride in memory operand when base is a pointer which is 64 bits. Cast stride to __PTRDIFF_TYPE__, instead of long. PR target/106714 * config/i386/amxtileintrin.h (_tile_loadd_internal): Cast to __PTRDIFF_TYPE__. (_tile_stream_loadd_internal): Likewise. (_tile_stored_internal): Likewise.
[Bug target/106724] New: logical-op-non-short-circuit maybe should be 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106724
Bug ID: 106724
Summary: logical-op-non-short-circuit maybe should be 1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: riscv
Take:
int f(int a, int b, int c, int d)
{
return a > b && c > d;
}
CUT ---
Currently on riscv32 at -O2 produces:
f:
ble a0,a1,.L3
sgt a0,a2,a3
ret
.L3:
li a0,0
ret
But add --param logical-op-non-short-circuit=1, produces:
f:
sgt a0,a0,a1
sgt a2,a2,a3
and a0,a0,a2
ret
Which is much better, especially on in-order cores.
[Bug tree-optimization/106722] bogus uninit warning in tree-vect-loop-manip.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106722 --- Comment #6 from Andrew Pinski --- Note I think for RISCV, logical-op-non-short-circuit seems like it should change to 1, I filed PR 106724 for that with an example even.
[Bug debug/106719] [10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2 since r10-6038-ge5e07b68187b9a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106719 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5
[Bug target/106724] logical-op-non-short-circuit maybe should be 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106724 --- Comment #1 from Andrew Pinski --- Note clang/LLVM produces the branch-less version also.
[Bug libstdc++/106589] [12/13 Regression] visit rejects lambdas that do not return void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106589 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e85bb1881e57e53306ede2a15f30d06480d69886 commit r13-2157-ge85bb1881e57e53306ede2a15f30d06480d69886 Author: Jonathan Wakely Date: Tue Aug 23 15:46:16 2022 +0100 libstdc++: Fix visit(v) for non-void visitors [PR106589] The optimization for the common case of std::visit forgot to handle the edge case of passing zero variants to a non-void visitor and converting the result to void. libstdc++-v3/ChangeLog: PR libstdc++/106589 * include/std/variant (__do_visit): Handle is_void for zero argument case. * testsuite/20_util/variant/visit_r.cc: Check std::visit(v).
[Bug libstdc++/106589] [12 Regression] visit rejects lambdas that do not return void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106589 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Keywords|needs-bisection | Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Known to fail||12.2.0 Summary|[12/13 Regression] |[12 Regression] visit |visit rejects lambdas |rejects lambdas that do not |that do not return void |return void
[Bug target/106724] logical-op-non-short-circuit maybe should be 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106724
--- Comment #2 from Andrew Pinski ---
Well branch cost should be more tuned too.
Here is an example where BRANCH_COST=4 is needed to get one branch:
```
int g(void);
int f(int a, int b, int c, int d)
{
if (a > b && c > d)
return g();
return 1;
}
```
Note clang/LLVM produces much worse code (two xori which are not needed).
[Bug libstdc++/106676] [C++20] Automatic iterator_category detection misbehaves when `::reference` is an rvalue reference, refuses to accept a forward iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106676 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- I'm not sure it's a wording defect - I think this was a deliberate design choice. But it's likely to be relaxed. In any case, libstdc++ correctly implements the standard. If the standard is relaxed, we'll change too.
[Bug libstdc++/106669] incorrect definition of viewable_range ("more madness with move-only views")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106669 --- Comment #2 from Jonathan Wakely --- Please open an LWG issue.
[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516 --- Comment #6 from Peter Bergner --- (In reply to Kewen Lin from comment #5) > Created attachment 53492 [details] > Adjust pr104992.c with vect_int_mod > > > So it sounds like we want a generic target supports test that is true on > > targets (like power10) with a vector mod and key off that. Any ideas how we > > can do that? > > Add one effective target vect_int_mod for it, one quick grepping for i386 > and aarch64 shows they don't have such support. Heh, I was thinking of whether we could actually test whether an actual target supported it, but given no other arches seem to be failing this test case other than P10, I guess that will work. :-)
[Bug c/106725] New: LTO semantics for __attribute__((leaf))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106725
Bug ID: 106725
Summary: LTO semantics for __attribute__((leaf))
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dthorn at google dot com
Target Milestone: ---
After implementing GCC's `__attribute__((leaf))` in Clang/LLVM, discussion
arose (https://reviews.llvm.org/D131628#3740602) about the semantics of LTO.
It seems like merging together object files in LTO might or might notproduce
erroneous results, depending on how the term "compilation unit" in the docs are
interpreted.
A minimal example consists of three source files:
main.c:
__attribute__((leaf)) void foo(void);
int main(void) {
foo();
return 0;
}
foo.c:
void bar(void);
void foo(void) {
bar();
}
bar.c:
void bar(void) {}
If "compilation unit" in the `__attribute__((leaf))` manual means "translation
unit", `__attribute__((leaf))` should be valid in main.c, since foo() only
calls bar(), which is not in the main.c translation unit.
Compile main.c and bar.c to LTO GIMPLE, but compile foo.c without LTO:
$ gcc -flto -c main.c bar.c
$ gcc -c foo.c
The resulting GIMPLE and object files can then be linked together and the LTO
trees dumped (Here I'm using -nostdlib just because I built gcc in isolation).
I installed a simple printf hack to gimple-pretty-print to print "leaf" if
ECF_LEAF is set on a printed call. This gives the following results:
$ gcc -fdump-tree-all main.o bar.o foo.o
$ cat a.ltrans0.ltrans.252t.optimized
<...>
int main ()
{
<...>
foo (); check 1 1024 leaf
<...>
}
;; Function bar (bar, funcdef_no=1, decl_uid=4720, cgraph_uid=1,
symbol_order=2)
<...>
>From the above, it appears that the main and bar translation units are merged
together by LTO to form a new module without altering the
`__attribute__((leaf))` semantics given on the call to foo() in main().
If "compilation unit" is interpreted as "translation unit", this may be
incorrect behavior, since any post-LTO passes that are expecting that foo()
cannot call bar() (since it's in the same TU) would have their expectations
violated.
If instead "compilation unit" is interpreted as "LTO unit", `then the above
program has undefined behavior, since `__attribute__((leaf)) should never have
been used on foo(), since it calls something (bar()) in the same LTO unit as
main.c.
Accordingly, if "compilation unit" means "translation unit" and this case is
incorrect behavior, this bug is to report this.
If "compilation unit" instead means "LTO unit", this bug is to request
clarification in the GCC manual about the precise behavior in case of LTO.
Finally, if "compilation unit" means "translation unit", but GCC has some other
internal mechanisms for dealing with this, feel free to close this. Please do
report back with those mechanisms though, as we'll have to do something similar
in LLVM in that case. It still may be worth altering the docs, given the
ambiguity in the term "compilation unit" in the presence of LTO.
System: Debian rodete
GCC build commands used:
../configure --disable-bootstrap --enable-languages=c,c++,lto \
--prefix=$(realpath ..)/gcc-install
make -j96 -l96 all-gcc
make install-gcc
[Bug sanitizer/106726] New: ICE: verify_gimple failed (dead statement in EH table) on __builtin_alloca_with_align() with -fsanitize=hwaddress -fstack-check=generic -fexceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106726 Bug ID: 106726 Summary: ICE: verify_gimple failed (dead statement in EH table) on __builtin_alloca_with_align() with -fsanitize=hwaddress -fstack-check=generic -fexceptions Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: aarch64-unknown-linux-gnu Created attachment 53497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53497&action=edit reduced testcase Compiler output: $ aarch64-unknown-linux-gnu-gcc -fsanitize=hwaddress -fstack-check=generic -fexceptions testcase.c testcase.c: In function 'foo': testcase.c:4:1: error: dead statement in EH table 4 | foo (void) | ^~~ # _4 = VDEF <.MEM_2> _5 = __builtin_alloca_with_align (64, 128); during GIMPLE pass: asan0 testcase.c:4:1: internal compiler error: verify_gimple failed 0x11c2f4a verify_gimple_in_cfg(function*, bool) /repo/gcc-trunk/gcc/tree-cfg.cc:5568 0x1066e47 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2091 0x10673eb execute_todo /repo/gcc-trunk/gcc/passes.cc:2145 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. $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-2159-20220823134237-g72886fcc626-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.0/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-2159-20220823134237-g72886fcc626-checking-yes-rtl-df-extra-aarch64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20220823 (experimental) (GCC)
[Bug libstdc++/105678] Undefined reference to stacktrace standard library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678 --- Comment #10 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c9c0684ad3092e5aa50453903c09959cb2e83fc7 commit r12-8707-gc9c0684ad3092e5aa50453903c09959cb2e83fc7 Author: Jonathan Wakely Date: Mon Aug 22 17:24:27 2022 +0100 libstdc++: Document linker option for C++23 [PR105678] libstdc++-v3/ChangeLog: PR libstdc++/105678 * doc/xml/manual/using.xml: Document -lstdc++_libbacktrace requirement for using std::stacktrace. Also adjust -frtti and -fexceptions to document non-default (i.e. negative) forms. * doc/html/*: Regenerate. (cherry picked from commit cc4fa7a210b638d6a46f14dab17f2361389d18e1)
[Bug libstdc++/105678] Undefined reference to stacktrace standard library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105678 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jonathan Wakely --- Fixed for 12.3 and 13.
[Bug fortran/103694] [12/13 Regression] ICE in gfc_conv_expr_op, at fortran/trans-expr.c:3882 since r12-3993-gb19bbfb148250536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103694
--- Comment #6 from anlauf at gcc dot gnu.org ---
Potential fix that regtests cleanly:
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index f992c31e5d7..3d2a68fa36a 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -7536,8 +7537,9 @@ simplify_size (gfc_expr *array, gfc_expr *dim, int k)
}
for (ref = array->ref; ref; ref = ref->next)
-if (ref->type == REF_ARRAY && ref->u.ar.as)
- gfc_resolve_array_spec (ref->u.ar.as, 0);
+if (ref->type == REF_ARRAY && ref->u.ar.as
+ && !gfc_resolve_array_spec (ref->u.ar.as, 0))
+ return NULL;
if (dim == NULL)
{
[Bug fortran/103694] [12/13 Regression] ICE in gfc_conv_expr_op, at fortran/trans-expr.c:3882 since r12-3993-gb19bbfb148250536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103694 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-August/058080.html
[Bug libfortran/106509] executable hangs if -static is included in compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106509 --- Comment #4 from GARY.WHITE at ColoState dot edu --- Somewhat resolved -- does not happen with UCRT, only with MSVCRT.
[Bug c++/69410] [10/11/12/13 Regression] friend declarations in local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410 --- Comment #8 from Zopolis0 --- Created attachment 53498 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53498&action=edit Possible patch This is a more production-ready version of the patch I used, gcc completes a full no bootstrap build with this.
[Bug target/106721] Error: invalid character '<' in mnemonic since r13-2122-g86c0d98620ee3a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106721 --- Comment #4 from Hongtao.liu --- (In reply to Jakub Jelinek from comment #3) > Created attachment 53494 [details] > gcc13-pr106721.patch > > Untested fix. This fixes all <[a-zA-Z] occurrences in tmp-mddump.md (except > those in comments). Whether for V*BF or V*HF modes it is better to use i or > f suffixed broadcast etc. is something I have no idea about, used f for now. Maybe we should align them with V*HImode like other vector shuffle, broadcast instructions, which means use i instead? Others LGTM, thanks for the fix.
[Bug c++/106689] gcc crash while compiling a generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #9 from Andrew Pinski --- Dup of bug 100295. *** This bug has been marked as a duplicate of bug 100295 ***
[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295 Andrew Pinski changed: What|Removed |Added CC||janezz55 at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 106689 has been marked as a duplicate of this bug. ***
[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516 --- Comment #7 from Kewen Lin --- (In reply to Peter Bergner from comment #6) > (In reply to Kewen Lin from comment #5) > > Created attachment 53492 [details] > > Adjust pr104992.c with vect_int_mod > > > > > So it sounds like we want a generic target supports test that is true on > > > targets (like power10) with a vector mod and key off that. Any ideas how > > > we > > > can do that? > > > > Add one effective target vect_int_mod for it, one quick grepping for i386 > > and aarch64 shows they don't have such support. > > Heh, I was thinking of whether we could actually test whether an actual > target supported it, but given no other arches seem to be failing this test > case other than P10, I guess that will work. :-) Thanks for the clarification, I guess that's doable. In this patch, I mainly followed the existing practice vect_int_mult (there are also some similar effective targets describing target vector support capability). With this way, if some other arches support this in future, target owners need to add their own conditions.
[Bug target/103353] Indefinite recursion when compiling -mmma requiring testcase w/ -maltivec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103353 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:d0d72e0b1ebbac487d70281a56799bf547034ec1 commit r12-8709-gd0d72e0b1ebbac487d70281a56799bf547034ec1 Author: Kewen.Lin Date: Tue Aug 16 00:24:07 2022 -0500 rs6000: Adjust mov optabs for opaque modes [PR103353] As PR103353 shows, we may want to continue to expand built-in function __builtin_vsx_lxvp, even if we have already emitted error messages about some missing required conditions. As shown in that PR, without one explicit mov optab on OOmode provided, it would call emit_move_insn recursively. So this patch is to allow the mov pattern to be generated during expanding phase if compiler has already seen errors. PR target/103353 gcc/ChangeLog: * config/rs6000/mma.md (define_expand movoo): Move TARGET_MMA condition check to preparation statements and add handlings for !TARGET_MMA. (define_expand movxo): Likewise. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr103353.c: New test. (cherry picked from commit 9367e3a65f874dffc8f8a3b6760e77fd9ed67117)
[Bug tree-optimization/106322] [12 Regression] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working) since r12-2404-ga1d27560770818c5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322 --- Comment #48 from CVS Commits --- The releases/gcc-12 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:9f532fec01d6651cc3cc136073f044a7953d8560 commit r12-8710-g9f532fec01d6651cc3cc136073f044a7953d8560 Author: Kewen Lin Date: Tue Aug 16 00:18:51 2022 -0500 vect: Don't allow vect_emulated_vector_p type in vectorizable_call [PR106322] As PR106322 shows, in some cases for some vector type whose TYPE_MODE is a scalar integral mode instead of a vector mode, it's possible to obtain wrong target support information when querying with the scalar integral mode. For example, for the test case in PR106322, on ppc64 32bit vectorizer gets vector type "vector(2) short unsigned int" for scalar type "short unsigned int", its mode is SImode instead of V2HImode. The target support querying checks umul_highpart optab with SImode and considers it's supported, then vectorizer further generates .MULH IFN call for that vector type. Unfortunately it's wrong to use SImode support for that vector type multiply highpart here. This patch is to teach vectorizable_call analysis not to allow vect_emulated_vector_p type for both vectype_in and vectype_out as Richi suggested. PR tree-optimization/106322 gcc/ChangeLog: * tree-vect-stmts.cc (vectorizable_call): Don't allow vect_emulated_vector_p type for both vectype_in and vectype_out. gcc/testsuite/ChangeLog: * gcc.target/i386/pr106322.c: New test. * gcc.target/powerpc/pr106322.c: New test. (cherry picked from commit 5239e2bd48fb1e6a1d1b06a1bac49bee0a742e98)
[Bug target/103353] Indefinite recursion when compiling -mmma requiring testcase w/ -maltivec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103353 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:3fc2a9dba4c06115daaa8a39acffadbc33b51152 commit r11-10220-g3fc2a9dba4c06115daaa8a39acffadbc33b51152 Author: Kewen.Lin Date: Tue Aug 16 00:24:07 2022 -0500 rs6000: Adjust mov optabs for opaque modes [PR103353] As PR103353 shows, we may want to continue to expand built-in function __builtin_vsx_lxvp, even if we have already emitted error messages about some missing required conditions. As shown in that PR, without one explicit mov optab on OOmode provided, it would call emit_move_insn recursively. So this patch is to allow the mov pattern to be generated during expanding phase if compiler has already seen errors. PR target/103353 gcc/ChangeLog: * config/rs6000/mma.md (define_expand movoo): Move TARGET_MMA condition check to preparation statements and add handlings for !TARGET_MMA. (define_expand movxo): Likewise. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr103353.c: New test. (cherry picked from commit 9367e3a65f874dffc8f8a3b6760e77fd9ed67117)
[Bug target/103353] Indefinite recursion when compiling -mmma requiring testcase w/ -maltivec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103353 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:501fba663052b0b4a1eb6a42c32b74c254cbedbc commit r10-10959-g501fba663052b0b4a1eb6a42c32b74c254cbedbc Author: Kewen Lin Date: Tue Aug 23 03:31:17 2022 -0500 rs6000: Adjust mov optabs for opaque modes [PR103353] As PR103353 shows, we may want to continue to expand built-in function __builtin_vsx_lxvp, even if we have already emitted error messages about some missing required conditions. As shown in that PR, without one explicit mov optab on OOmode provided, it would call emit_move_insn recursively. So this patch is to allow the mov pattern to be generated during expanding phase if compiler has already seen errors. PR target/103353 gcc/ChangeLog: * config/rs6000/mma.md (define_expand movpoi): Move TARGET_MMA condition check to preparation statements and add handlings for !TARGET_MMA. (define_expand movpxi): Likewise. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr103353.c: New test. (cherry picked from commit 9367e3a65f874dffc8f8a3b6760e77fd9ed67117)
[Bug target/103353] Indefinite recursion when compiling -mmma requiring testcase w/ -maltivec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103353 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Kewen Lin --- Fixed everywhere.
[Bug tree-optimization/106727] New: Missed fold / canonicalization for checking if a number is a power of 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106727
Bug ID: 106727
Summary: Missed fold / canonicalization for checking if a
number is a power of 2
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: llvm at rifkin dot dev
Target Milestone: ---
These two are equivalent but generate different code:
bool foo(unsigned n) {
return std::popcount(n) <= 1;
}
bool bar(unsigned n) {
return (n & (n - 1)) == 0;
}
https://godbolt.org/z/crrxnfWo7
For systems that don't have popcount instructions it would be very beneficial
to transform foo -> bar. For systems that do have popcount instructions it
still would be beneficial to canonicalize the two.
[Bug tree-optimization/106322] [12 Regression] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working) since r12-2404-ga1d27560770818c5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322 --- Comment #49 from Kewen Lin --- Hi Richi, One thing I'm not sure about is that if we want to backport this to gcc-11 and gcc-10? Although the failure got exposed by .MULH pattern recog which is only in gcc-12, IMHO the underlying issue exists in gcc-10 and gcc-11.
[Bug middle-end/106727] Missed fold / canonicalization for checking if a number is a power of 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106727 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|tree-optimization |middle-end
[Bug rtl-optimization/106418] '-fcompare-debug' failure w/ -mcpu=e500mc -O2 -fnon-call-exceptions -fsched-stalled-insns -fno-reorder-blocks -fno-thread-jumps -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106418 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||jskumari at gcc dot gnu.org --- Comment #1 from Peter Bergner --- Surya, might this be related to the sched1 -fcompare-debug issue you have a patch for? Or is this something new?
[Bug target/100736] ICE: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736 --- Comment #5 from Peter Bergner --- (In reply to Segher Boessenkool from comment #3) > Send patches to gcc-patches@, please. Or is there a question? Ask that > question then, please :-) Segher, do you have an answer for Hao Chen's question in Comment #4?
[Bug sanitizer/106726] ICE: verify_gimple failed (dead statement in EH table) on __builtin_alloca_with_align() with -fsanitize=hwaddress -fstack-check=generic -fexceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106726 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-08-24 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- >From bug 104449 comment #6 : "I haven't touched the hwasan code which most likely suffers from the same problem. " Yes so confirmed.
[Bug c++/106728] New: Cannot Compile EXE on Shared Network Drive (Windows, MinGW)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728 Bug ID: 106728 Summary: Cannot Compile EXE on Shared Network Drive (Windows, MinGW) Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: johntravolski1 at gmail dot com Target Milestone: --- If I compile with: g++ -std=c++11 iterate.cpp -o "\\machine_name\d\performance testing\out.exe" I get this output and no .exe file: c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot open output file \\machine_name\d\performance testing\out.exe: Invalid argument collect2.exe: error: ld returned 1 exit status If I change the output path to a system drive rather than one on the network, it compiles fine. It gives the same error if I use a local, rather than absolute, path as well (and have the working directory on the network drive [my working directory can be a UNC path in PowerShell]). Unfortunately, mapping to a drive letter also does not work: g++ -std=c++11 iterate.cpp -o "Z:\28sec\out.exe" gives c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot open output file Z:\28sec\out.exe: No such file or directory collect2.exe: error: ld returned 1 exit status I am not sure if this is relevant, but I have a much older version of MinGW from Winbuilds (I installed from win-builds-1.5.0.exe sometime back in 2018), and it is able to output the compiled exe directly to network drives just fine. Here's the gcc version info of the version with the issue: gcc.exe -v Using built-in specs. COLLECT_GCC=C:\MinGW64_cpp17\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw64_cpp17/bin/../libexec/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper.exe OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-w64-mingw32 Configured with: ../configure --prefix=/r/winlibs64_stage/11532.gcc/inst_gcc-12.2.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders' --with-tune=generic --enable-checking=release --enable-threads=posix --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap --enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath --disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs --disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++,jit --disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry --disable-multilib --enable-ld --enable-libquadmath --enable-libada --enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp --enable-graphite --enable-mingw-wildcard --enable-libstdcxx-time --disable-libstdcxx-pch --with-mpc=/d/Prog/winlibs64_stage/custombuilt --with-mpfr=/d/Prog/winlibs64_stage/custombuilt --with-gmp=/d/Prog/winlibs64_stage/custombuilt --with-isl=/d/Prog/winlibs64_stage/custombuilt --enable-libstdcxx-backtrace --enable-install-libiberty --enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto --enable-clocale=generic --with-libiconv --with-system-zlib --with-build-sysroot=/r/winlibs64_stage/11532.gcc/gcc-12.2.0/build_mingw/mingw-w64 CFLAGS='-I/d/Prog/winlibs64_stage/custombuilt/include/libdl-win32 -D__USE_MINGW_ACCESS' CXXFLAGS=-D__USE_MINGW_ACCESS LDFLAGS='-Wl,--disable-nxcompat -Wl,--disable-high-entropy-va -Wl,--disable-dynamicbase' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders) Here's the old build from 2018 where this isn't an issue: gcc.exe -v Reading specs from c:/mingw/bin/../lib64/gcc/x86_64-w64-mingw32/4.8.3/specs COLLECT_GCC=C:\MingW\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.3/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-4.8.3/configure --prefix=/opt/windows_64 --with-sysroot=/opt/windows_64 --libdir=/opt/windows_64/lib64 --mandir=/opt/windows_64/man --infodir=/opt/windows_64/info --enable-shared --disable-bootstrap --disable-multilib --enable-threads=posix --enable-languages=c,c++ --enable-checking=release --enable-libgomp --with-system-zlib --with-python-dir=/lib64/python2.7/site-packages --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose --enable-java-home --with-java-home=/opt/windows_64/lib64/jvm/jre --with-jvm-root-dir=/opt/windows_64/lib64/jvm --with-jvm-jar-dir=/opt/windows_64/lib64/jvm/jvm-exports --with-arch-directory=amd64 --with-antlr-jar='/home/adrien/projects/win-builds-1.5/slackware64-current/d/gcc/antlr-*.jar' --disable-java-awt --disable-gtktest --build=x86_64-slackware-linux --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 Thread model: p
[Bug c++/106729] New: Missing diagnostic for violation of 9.2.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106729
Bug ID: 106729
Summary: Missing diagnostic for violation of 9.2.8.5
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: whh8b at obs dot cr
Target Milestone: ---
According to 9.2.8.5 of the C++ standard, the following code should produce a
diagnostic:
void testing() {
return;
}
inline void testing();
int main() {
return 0;
}
I can confirm that clang++ v 14.0.0 produces the proper diagnostic.
[Bug fortran/106730] New: [OpenMP] ICE in install_var_field, at omp-low.cc:797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106730 Bug ID: 106730 Summary: [OpenMP] ICE in install_var_field, at omp-low.cc:797 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, openmp Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 53499 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53499&action=edit Slightly modified and de-module-used testcase; run as 'gfortran -fopenmp test.f90' Found via https://github.com/SOLLVE/sollve_vv/blob/master/tests/5.0/target/test_target_mapping_before_alloc.F90 Testcase fails since at least GCC 9. $ gfortran -fopenmp test.f90 during GIMPLE pass: omplower test.f90:25:41: 25 | !$omp& test_struct) map(tofrom: errors) | ^ internal compiler error: in install_var_field, at omp-low.cc:797 0x742f21 install_var_field ../../repos/gcc-trunk-commit/gcc/omp-low.cc:797 0xe24f0c scan_sharing_clauses ../../repos/gcc-trunk-commit/gcc/omp-low.cc:1672 0xe26877 scan_omp_target ../../repos/gcc-trunk-commit/gcc/omp-low.cc:3100
[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #18 from Andreas Krebbel ---
(In reply to Segher Boessenkool from comment #17)
...
> Yes, but that says the high 48 bits of the hardware reg are untouched, which
> is not true (only the high 16 of the low 32 are guaranteed unmodified).
Right, if the original register mode does not match the mode of the full
hardreg, we continue to need that mode as the upper bound. So with the subreg
folding in reload we appear to loose information we need to interpret the
STRICT_LOW_PART correctly.
I'm testing the following patch in combination with my other fix now:
diff --git a/gcc/lra-spills.cc b/gcc/lra-spills.cc
index 4ddbe477d92..9c125a9ce38 100644
--- a/gcc/lra-spills.cc
+++ b/gcc/lra-spills.cc
@@ -855,6 +855,7 @@ lra_final_code_change (void)
for (i = id->insn_static_data->n_operands - 1; i >= 0; i--)
if ((DEBUG_INSN_P (insn) || ! static_id->operand[i].is_operator)
+ && ! static_id->operand[i].strict_low
&& alter_subregs (id->operand_loc[i], ! DEBUG_INSN_P (insn)))
{
lra_update_dup (id, i);
With that change the SUBREG folding from comment #11 happens later in final
(cleanup_subreg_operands). I'm not sure whether we would have to prevent it
there as well?!
[Bug tree-optimization/106322] [12 Regression] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working) since r12-2404-ga1d27560770818c5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to work||12.2.1 Status|ASSIGNED|RESOLVED Known to fail||12.2.0 --- Comment #50 from Richard Biener --- (In reply to Kewen Lin from comment #49) > Hi Richi, > > One thing I'm not sure about is that if we want to backport this to gcc-11 > and gcc-10? Although the failure got exposed by .MULH pattern recog which is > only in gcc-12, IMHO the underlying issue exists in gcc-10 and gcc-11. It's enough to backport to 12.
[Bug fortran/106730] [OpenMP][valid since 5.0] ICE in install_var_field, at omp-low.cc:797 for 'map(alloc:var) map(to:var)' (more than once in map clause)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106730 Tobias Burnus changed: What|Removed |Added Summary|[OpenMP] ICE in |[OpenMP][valid since 5.0] |install_var_field, at |ICE in install_var_field, |omp-low.cc:797 |at omp-low.cc:797 for ||'map(alloc:var) ||map(to:var)' (more than ||once in map clause) --- Comment #1 from Tobias Burnus --- Okay – that's the ‘member’ appears more than once in map clauses issue For C/C++, there is this error – for Fortran not: error: ‘member’ appears more than once in map clauses (same for 'a' and 'scalar') using the C testcase at https://github.com/SOLLVE/sollve_vv/blob/master/tests/5.0/target/test_target_mapping_before_alloc.c for the C/C++ testcase. I think one pending patch was addressing on this. Indeed, using devel/omp/gcc-12 (OG12), it compiles + runs for Fortran - but still fails for C/C++ with the "more than once" error. I think it is part of the following patch set: * [PATCH 00/16] OpenMP: lvalues in "map" clauses and struct handling rework https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586600.html and January + February updates (search for metadirective) + patch review end of May, e.g. https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595762.html (+ 4 more emails)
