[Bug tree-optimization/101746] [12 regression] gcc.dg/tree-prof/20050826-2.c and gcc.dg/uninit-pred-9_b.c fail since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101746 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > I can confirm gcc.dg/tree-prof/20050826-2.c fails even on x86_64-linux-gnu. I think this has been fixed now.
[Bug c/102867] [12 Regression] Waddress complaint in readelf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867 Andrew Pinski changed: What|Removed |Added Summary|Waddress complaint in |[12 Regression] Waddress |readelf.c |complaint in readelf.c Target Milestone|--- |12.0 Keywords||diagnostic
[Bug c/102867] Waddress complaint in readelf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867 --- Comment #1 from Alan Modra --- Created attachment 51641 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51641=edit preprocessed source
[Bug c/102867] New: Waddress complaint in readelf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867
Bug ID: 102867
Summary: Waddress complaint in readelf.c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
Compiling the attached readelf.i with -Wall -Werror -O2 using today's gcc
mainline on x86_64-linux results in complaints like
/home/alan/src/binutils-gdb/binutils/readelf.c: In function ‘find_section’:
/home/alan/src/binutils-gdb/binutils/readelf.c:762:42: error: the comparison
will always evaluate as ‘true’ for the pointer operand in
‘filedata->section_headers + (sizetype)((long unsigned int)i * 80)’ must not be
NULL [-Werror=address]
762 | if (SECTION_NAME_VALID (filedata->section_headers + i)
The warning is true, but annoying when coming from a macro expansion
#define SECTION_NAME_VALID(X) \
((X) != NULL \
&& filedata->string_table != NULL\
&& (X)->sh_name < filedata->string_table_length)
In current readelf.c it looks like it may be possible to remove "(X) != NULL"
from this macro, but that doesn't seem like a good solution. Another macro
with similar complaints
#define SECTION_NAME_PRINT(X) \
((X) == NULL ? _("")\
: filedata->string_table == NULL ? _("") \
: (X)->sh_name >= filedata->string_table_length ? _("") \
: filedata->string_table + (X)->sh_name)
can be called with X NULL.
[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 --- Comment #3 from Andrew Pinski --- *** Bug 102778 has been marked as a duplicate of this bug. ***
[Bug c++/102778] cannot parameter pack std::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102778 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #2 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||benni.probst at gmx dot de --- Comment #2 from Andrew Pinski --- *** Bug 102866 has been marked as a duplicate of this bug. ***
[Bug c++/102866] Unexpected error on variadic forwarding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102866 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 100295. *** This bug has been marked as a duplicate of bug 100295 ***
[Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 --- Comment #8 from Qiu Chaofan --- > Looks like we need two different versions of that symbol, with different > mangled names. Yes, I did a little hack: adding another symbol `__convert_from_v_ieee128` (guarded under macro __LONG_DOUBLE_IEEE128__), and use the macro to determine call `__convert_from_v_ieee128` or `__convert_from_v` in callers, which shows expected result.
[Bug bootstrap/102865] gcc-12.0 HEAD fails to compile on x86_64 Darwin: unknown machine mode ‘HF’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102865 Heather A changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED
[Bug bootstrap/102865] gcc-12.0 HEAD fails to compile on x86_64 Darwin: unknown machine mode ‘HF’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102865 --- Comment #3 from Heather A --- Ha, okay. I figured it out. It was totally bad on my side. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7cbc870c495cebc61f5d0ebb975856c207a42fab resolved this issue. I was going insane trying to figure out why ix86_scalar_mode_supported_p did not have a case like you just pointed out, but it was because this was actually off of gcc 11.2 with some backported functionality (from Iain Sandoe's Darwin aarch64 work). I thought it reproduced clearly on master, but I guess I messed up that test. Well, that's embarrassing. Thanks! And sorry about that!
[Bug c++/102866] New: Unexpected error on variadic forwarding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102866
Bug ID: 102866
Summary: Unexpected error on variadic forwarding
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: benni.probst at gmx dot de
Target Milestone: ---
Created attachment 51640
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51640=edit
A multi variant data container
I changed a push function to determine between containers that can execute
push_back and those who dont. The original line was just this->data =
this->create(args..., this->data); instead of the compile switch. At this point
the error occurred. The key is line 83 and 101
Sources cannot be uploaded because exe file is 1 Gigabyte in size
[ Build | UltiHash | Debug
]
/usr/local/bin/cmake --build
/home/benjamin/CLionProjects/UltiHash/cmake-build-debug --target UltiHash -j 8
Scanning dependencies of target UltiHash
[ 11%] Building CXX object CMakeFiles/UltiHash.dir/dataContainer.cpp.o
[ 22%] Building CXX object CMakeFiles/UltiHash.dir/main.cpp.o
In file included from
/home/benjamin/CLionProjects/UltiHash/aiHeuristics_runtime_tests.h:4,
from /home/benjamin/CLionProjects/UltiHash/main.cpp:8:
/home/benjamin/CLionProjects/UltiHash/dataContainer.h: In instantiation of
‘dataContainer::push_back >&>(std::vector&):: [with auto:124 = std::integral_constant]’:
/usr/local/include/boost/mp11/detail/mp_with_index.hpp:374:84: required by
substitution of ‘template constexpr decltype
(declval()(declval >()))
boost::mp11::mp_with_index(std::size_t, F&&) [with N =
std::integral_constant; F = dataContainer::push_back
>&>(std::vector&)::]’
/home/benjamin/CLionProjects/UltiHash/dataContainer.h:78:79: required from
‘void dataContainer::push_back(Args&& ...) [with Args =
{std::vector >&}; T = unsigned int;
alloc = {}]’
/home/benjamin/CLionProjects/UltiHash/dataContainer.h:1525:17: required from
‘dataContainer::benchmark(long unsigned int, long unsigned int,
internEnum, internEnum) [with auto:203
= std::integral_constant]’
/usr/local/include/boost/mp11/detail/mp_with_index.hpp:374:84: required by
substitution of ‘template constexpr decltype
(declval()(declval >()))
boost::mp11::mp_with_index(std::size_t, F&&) [with N =
std::integral_constant; F = dataContainer::benchmark(long unsigned int, long unsigned int, internEnum,
internEnum)]’
/home/benjamin/CLionProjects/UltiHash/dataContainer.h:1518:83: required from
‘dataContainer::benchmark(long unsigned int, long unsigned int,
internEnum, internEnum):: [with auto:202 =
std::integral_constant]’
/usr/local/include/boost/mp11/detail/mp_with_index.hpp:374:84: required by
substitution of ‘template constexpr decltype
(declval()(declval >()))
boost::mp11::mp_with_index(std::size_t, F&&) [with N =
std::integral_constant; F = dataContainer::benchmark(long unsigned int, long unsigned int, internEnum,
internEnum)::]’
/home/benjamin/CLionProjects/UltiHash/dataContainer.h:1497:79: required from
‘void dataContainer::benchmark(long unsigned int, long unsigned int,
internEnum, internEnum) [with T = unsigned int; alloc = {}; internEnum = long
unsigned int]’
/home/benjamin/CLionProjects/UltiHash/dataContainer.h:1496:10: required from
here
/home/benjamin/CLionProjects/UltiHash/dataContainer.h:83:55: internal compiler
error: trying to capture ‘args#0’ in instantiation of generic lambda
83 | this->data = this->create(this->data, args...);
| ^~~~
0x7c3781 add_capture(tree_node*, tree_node*, tree_node*, bool, bool)
../../gcc/cp/lambda.c:619
0x7c37f3 add_default_capture(tree_node*, tree_node*, tree_node*)
../../gcc/cp/lambda.c:679
0x87bd81 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:20916
0x87a742 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19650
0x87a742 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:21031
0x88bd14 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19650
0x88bd14 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:19200
0x88ac3a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18176
0x88ac3a gen_elem_of_pack_expansion_instantiation
../../gcc/cp/pt.c:12587
0x88ac3a tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:13250
0x87b517 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:20320
0x87b368 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19650
[Bug bootstrap/102865] gcc-12.0 HEAD fails to compile on x86_64 Darwin: unknown machine mode ‘HF’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102865 --- Comment #2 from Andrew Pinski --- Also these configure options seems odd: --with-newlib --disable-lto Why set CFLAGS/CPPFLAGS also?
[Bug bootstrap/102865] gcc-12.0 HEAD fails to compile on x86_64 Darwin: unknown machine mode ‘HF’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102865
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-10-21
Status|UNCONFIRMED |WAITING
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
HFmode should be supported:
static bool
ix86_scalar_mode_supported_p (scalar_mode mode)
{
if (DECIMAL_FLOAT_MODE_P (mode))
return default_decimal_float_supported_p ();
else if (mode == TFmode)
return true;
else if (mode == HFmode && TARGET_SSE2)
return true;
else
return default_scalar_mode_supported_p (mode);
}
SSE2 is default on for x86_64.
Are you sure that the first compiler is not miscompiling the new one?
[Bug bootstrap/102865] New: gcc-12.0 HEAD fails to compile on x86_64 Darwin: unknown machine mode ‘HF’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102865 Bug ID: 102865 Summary: gcc-12.0 HEAD fails to compile on x86_64 Darwin: unknown machine mode ‘HF’ Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: alpha+gcc at alphaservcomputing dot solutions Target Milestone: --- Created attachment 51639 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51639=edit Attempted (not very elegant) fix Latest GCC fails to build since 3ccb523bdd78e6ba3c133064be90cdf19dcbf896 on MacOS x86_64 without HF. Configuration: `./configure --with-system-zlib --disable-bootstrap --with-newlib --disable-multiarch --disable-multilib --enable-languages=fortran --disable-lto --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk` (CFLAGS/CPPFLAGS: `-fexceptions -Wformat -Werror=format-security -mmacosx-version-min=10.12 -fdebug-prefix-map=/private/var/folders/0s/n3s60vpj3xlb2k5v7yv9vc0cgq/T/qbws-xein9n_m/src=. -I/private/var/folders/0s/n3s60vpj3xlb2k5v7yv9vc0cgq/T/qbws-xein9n_m/buildenv/include -O2 -Wno-error=format-security -fno-exceptions -Wfatal-errors`) Build Failure: ``` /private/var/folders/0s/n3s60vpj3xlb2k5v7yv9vc0cgq/T/qbws-xein9n_m/src/host-x86_64-apple-darwin18.7.0/gcc/xgcc -B/private/var/folders/0s/n3s60vpj3xlb2k5v7yv9vc0cgq/T/qbws-xein9n_m/src/host-x86_64-apple-darwin18.7.0/gcc/ -B/private/var/folders/0s/n3s60vpj3xlb2k5v7yv9vc0cgq/T/qbws-xein9n_m/root/x86_64-apple-darwin18.7.0/bin/ -B/private/var/folders/0s/n3s60vpj3xlb2k5v7yv9vc0cgq/T/qbws-xein9n_m/root/x86_64-apple-darwin18.7.0/lib/ -isystem /private/var/folders/0s/n3s60vpj3xlb2k5v7yv9vc0cgq/T/qbws-xein9n_m/root/x86_64-apple-darwin18.7.0/include -isystem /private/var/folders/0s/n3s60vpj3xlb2k5v7yv9vc0cgq/T/qbws-xein9n_m/root/x86_64-apple-darwin18.7.0/sys-include -fdebug-prefix-map=/private/var/folders/0s/n3s60vpj3xlb2k5v7yv9vc0cgq/T/qbws-xein9n_m/src=. -g -fexceptions -Wformat -Werror=format-security -mmacosx-version-min=10.12 -fdebug-prefix-map=/private/var/folders/0s/n3s60vpj3xlb2k5v7yv9vc0cgq/T/qbws-xein9n_m/src=. -I/private/var/folders/0s/n3s60vpj3xlb2k5v7yv9vc0cgq/T/qbws-xein9n_m/buildenv/include -O2 -Wno-error=format-security -fno-exceptions -Wfatal-errors -O2 -g -fexceptions -Wformat -Werror=format-security -mmacosx-version-min=10.12 -fdebug-prefix-map=/private/var/folders/0s/n3s60vpj3xlb2k5v7yv9vc0cgq/T/qbws-xein9n_m/src=. -I/private/var/folders/0s/n3s60vpj3xlb2k5v7yv9vc0cgq/T/qbws-xein9n_m/buildenv/include -O2 -Wno-error=format-security -fno-exceptions -Wfatal-errors -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem ./include -mmacosx-version-min=10.8 -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -mmacosx-version-min=10.8 -fno-common -I. -I. -I../../host-x86_64-apple-darwin18.7.0/gcc -I../.././libgcc -I../.././libgcc/. -I../.././libgcc/../gcc -I../.././libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o sfp-exceptions_s.o -MT sfp-exceptions_s.o -MD -MP -MF sfp-exceptions_s.dep -DSHARED -c ../.././libgcc/config/i386/sfp-exceptions.c In file included from ../.././libgcc/config/i386/sfp-exceptions.c:25: ../.././libgcc/config/i386/sfp-machine.h:82:1: error: unknown machine mode ‘HF’ 82 | typedef float alias_HFtype __attribute__ ((mode (HF))); | ^~~ compilation terminated due to -Wfatal-errors. make[2]: *** [sfp-exceptions_s.o] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [all-target-libgcc] Error 2 make: *** [all] Error 2 ``` System: ``` $ uname -a Darwin mac-build-003 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64 $ sysctl -a | grep machdep.cpu machdep.cpu.max_basic: 22 machdep.cpu.max_ext: 2147483656 machdep.cpu.vendor: GenuineIntel machdep.cpu.brand_string: Intel(R) Core(TM) i5-8500B CPU @ 3.00GHz machdep.cpu.family: 6 machdep.cpu.model: 158 machdep.cpu.extmodel: 9 machdep.cpu.extfamily: 0 machdep.cpu.stepping: 10 machdep.cpu.feature_bits: 9221960262849657855 machdep.cpu.leaf7_feature_bits: 43806655 1073741824 machdep.cpu.leaf7_feature_bits_edx: 2617254912 machdep.cpu.extfeature_bits: 1241984796928 machdep.cpu.signature: 591594 machdep.cpu.brand: 0 machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C machdep.cpu.leaf7_features: RDWRFSGS TSC_THREAD_OFFSET SGX BMI1 HLE AVX2 SMEP BMI2 ERMS INVPCID RTM FPU_CSDS MPX RDSEED ADX SMAP
[Bug fortran/94070] Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070 --- Comment #12 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:1af78e731feb9327a17c99ebaa19a4cca1125caf commit r12-4591-g1af78e731feb9327a17c99ebaa19a4cca1125caf Author: Sandra Loosemore Date: Tue Oct 19 21:11:15 2021 -0700 Fortran: Fixes and additional tests for shape/ubound/size [PR94070] This patch reimplements the SHAPE intrinsic to be inlined similarly to LBOUND and UBOUND, instead of as a library call, to avoid an unnecessary array copy. Various bugs are also fixed. gcc/fortran/ PR fortran/94070 * expr.c (gfc_simplify_expr): Handle GFC_ISYM_SHAPE along with GFC_ISYM_LBOUND and GFC_ISYM_UBOUND. * trans-array.c (gfc_conv_ss_startstride): Likewise. (set_loop_bounds): Likewise. * trans-intrinsic.c (gfc_trans_intrinsic_bound): Extend to handle SHAPE. Correct logic for zero-size special cases and detecting assumed-rank arrays associated with an assumed-size argument. (gfc_conv_intrinsic_shape): Deleted. (gfc_conv_intrinsic_function): Handle GFC_ISYM_SHAPE like GFC_ISYM_LBOUND and GFC_ISYM_UBOUND. (gfc_add_intrinsic_ss_code): Likewise. (gfc_walk_intrinsic_bound): Likewise. gcc/testsuite/ PR fortran/94070 * gfortran.dg/c-interop/shape-bindc.f90: New test. * gfortran.dg/c-interop/shape-poly.f90: New test. * gfortran.dg/c-interop/size-bindc.f90: New test. * gfortran.dg/c-interop/size-poly.f90: New test. * gfortran.dg/c-interop/ubound-bindc.f90: New test. * gfortran.dg/c-interop/ubound-poly.f90: New test.
[Bug middle-end/36902] Array bound warning with dead code after optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902 Andrew Pinski changed: What|Removed |Added Known to fail|| Known to work|| Target Milestone|--- |4.5.0
[Bug tree-optimization/102703] [12 Regression] Dead Code Elimination Regression at -O3 since r12-2591-g2e96b5f14e402569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703 --- Comment #17 from Andrew Pinski --- Hmm, I get one regression: +FAIL: gcc.dg/pr36902.c (test for warnings, line 47) I filed PR 102864 and will change the testcase so we don't run into that issue.
[Bug tree-optimization/102864] New: no out of bounds warning for DCE code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102864
Bug ID: 102864
Summary: no out of bounds warning for DCE code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
int f(void)
{
int t[4]={0,0,0,0};
int t2 = 5;
int tt, tt1;
tt = t[t2];
tt1 = tt;
return tt-tt1;
}
There is no out of bounds warning for the t[t2] access because the code is all
dead.
[Bug middle-end/102764] [12 Regression] -fcompare-debug failure (length) at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102764
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #8 from H.J. Lu ---
The fix caused:
FAIL: gcc.dg/asan/pr78832.c -O1 (test for excess errors)
FAIL: gcc.dg/asan/pr78832.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (test for excess errors)
FAIL: gcc.dg/asan/pr78832.c -O2 (test for excess errors)
FAIL: gcc.dg/asan/pr78832.c -O3 -g (test for excess errors)
FAIL: gcc.dg/asan/pr78832.c -Os (test for excess errors)
FAIL: gcc.dg/pr45055.c (test for excess errors)
FAIL: gcc.dg/pr45105.c (test for excess errors)
FAIL: gcc.dg/pr45865.c (test for excess errors)
FAIL: gcc.dg/torture/pr48343.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/pr48343.c -Os (test for excess errors)
FAIL: gcc.target/i386/pr57106.c (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-4531/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="asan.exp=gcc.dg/asan/pr78832.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="asan.exp=gcc.dg/asan/pr78832.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr45055.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr45055.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr45105.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr45105.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr45865.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr45865.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg-torture.exp=gcc.dg/torture/pr48343.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg-torture.exp=gcc.dg/torture/pr48343.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr57106.c --target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr57106.c --target_board='unix{-m32\
-march=cascadelake}'"
[Bug middle-end/102857] [12 regression] r12-4526 caused regressions on vect/bb-slp-16.c and ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 --- Comment #1 from Andrew Pinski --- For me on x86_64 I get: gcc.dg/tree-ssa/ssa-dom-thread-7.c: dump file does not exist UNRESOLVED: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump-not vrp-thread2 "Jumps threaded"
[Bug target/102812] Unoptimal (and wrong) code for _Float16 insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102812
--- Comment #4 from Hongtao.liu ---
(In reply to Hongyu Wang from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > Please note that the code above should compile via ix86_expand_vector_set,
> > similar to:
> >
> > --cut here--
> > typedef short v8hi __attribute__((__vector_size__(16)));
> >
> > v8hi foo (short a)
> > {
> > return (v8hi) {a, 0, 0, 0, 0, 0, 0, 0 };
> > }
> > --cut here--
> >
> > that results in:
> >
> > vpxor %xmm0, %xmm0, %xmm0
> > vpinsrw $0, %edi, %xmm0, %xmm0
> > ret
>
> Currently we have
>
> if (TARGET_AVX512FP16 && VALID_AVX512FP16_REG_MODE (mode))
> return true;
>
> in ix86_vector_mode_supported_p, so for SSE2 target V8HFmode would be
> returned in BLKmode.
>
> After I put V8HFmode to VALID_SSE2_REG_MODE the code would be like
>
> vmovss %xmm0, %xmm0, %xmm1
> vpxor %xmm0, %xmm0, %xmm0
> pextrw $0, %xmm1, -10(%rsp)
> vpinsrw $0, -10(%rsp), %xmm0, %xmm0
>
> Seems IRA spills the HF reg to memory..
>
> I wonder whether we should move vector mode support to sse2 for now, as we
> don't have sufficient HF vector arithmetic emulation for non-avx512fp16
> target.
Acccording to document, maybe we can.
@deftypefn {Target Hook} bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode
@var{mode})
Define this to return nonzero if the port is prepared to handle
insns involving vector mode @var{mode}. At the very least, it
must have move patterns for this mode.
@end deftypefn
[Bug libstdc++/102863] Optional monadic ops should not be constrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102863 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jonathan Wakely --- Fixed, thanks.
[Bug libstdc++/102863] Optional monadic ops should not be constrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102863 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:0fac85a24f40ef6098b756e8e8655205f4bfbf3e commit r12-4586-g0fac85a24f40ef6098b756e8e8655205f4bfbf3e Author: Jonathan Wakely Date: Thu Oct 21 01:19:45 2021 +0100 libstdc++: Remove constraints from std::optional monadic ops [PR102863] The constraints on transform and and_then can cause errors when checking satisfaction. The constraints that were present in R6 of the paper were moved for he final F8 revision, and so should have been included in the implementation. libstdc++-v3/ChangeLog: PR libstdc++/102863 * include/std/optional (optional::and_then, optional::transform): Remove requires-clause. * testsuite/20_util/optional/monadic/and_then.cc: Check overload resolution doesn't cause errors. * testsuite/20_util/optional/monadic/transform.cc: Likewise.
[Bug libstdc++/102863] Optional monadic ops should not be constrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102863 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |12.0 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2021-10-20 --- Comment #1 from Jonathan Wakely --- Oh bother, I forgot to remove the constraints from my P0798R6 implementation (where they were present).
[Bug libstdc++/102863] New: Optional monadic ops should not be constrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102863
Bug ID: 102863
Summary: Optional monadic ops should not be constrained
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
It's important that these are not constrained with invocable; that constraint
can trigger hard errors during overload resolution. For instance:
void f(int&);
int main() {
std::optional x;
x.transform([](auto& y) { f(y); return 42; });
}
: In instantiation of 'main():: [with auto:3 = const
int]':
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:2565:26:
required by substitution of 'template static
std::__result_of_success()((declval<_Args>)()...)),
std::__invoke_other> std::__result_of_other_impl::_S_test(int) [with _Fn =
main()::; _Args = {const int&}]'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:2576:55:
required from 'struct std::__result_of_impl, const int&>'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:3038:12:
recursively required by substitution of 'template
struct std::__is_invocable_impl<_Result, _Ret, true, std::__void_t > [with _Result = std::__invoke_result,
const int&>; _Ret = void]'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:3038:12:
required from 'struct std::is_invocable, const
int&>'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:3286:71:
required from 'constexpr const bool
std::is_invocable_v, const int&>'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/concepts:336:25:
required by substitution of 'template requires invocable<_Fn,
const _Tp&> constexpr auto std::optional::transform(_Fn&&) const & [with
_Fn = int]'
:7:16: required from here
:7:32: error: binding reference of type 'int&' to 'const int' discards
qualifiers
7 | x.transform([](auto& y) { f(y); return 42; });
| ~^~~
:3:8: note: initializing argument 1 of 'void f(int&)'
3 | void f(int&);
|^~~~
[Bug fortran/102787] ICE in new test case gfortran.dg/reshape_shape_2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102787
--- Comment #7 from anlauf at gcc dot gnu.org ---
Slightly improved version of the patch of comment#6:
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 6552eaf3b0c..a63a6631f59 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -1812,6 +1812,29 @@ expand_constructor (gfc_constructor_base base)
continue;
}
+ /* Expand constant array within array constructor. */
+ if (e->expr_type == EXPR_VARIABLE && e->rank && e->ref
+ && e->symtree && e->symtree->n.sym
+ && e->symtree->n.sym->attr.flavor == FL_PARAMETER
+ && e->symtree->n.sym->value
+ && e->symtree->n.sym->value->value.constructor)
+ {
+ gfc_array_ref *ar;
+ ar = gfc_find_array_ref (e);
+ if (ar && ar->as && ar->as->type == AS_EXPLICIT)
+ {
+ if (ar->type == AR_FULL)
+ {
+ gfc_expr *value = e->symtree->n.sym->value;
+ if (!expand_constructor (value->value.constructor))
+ return false;
+
+ continue;
+ }
+ /* TODO: handle ar->type == AR_SECTION. */
+ }
+ }
+
empty_constructor = false;
e = gfc_copy_expr (e);
if (!gfc_simplify_expr (e, 1))
Still does not handle array sections.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #72 from Christoph Reiter --- Works nicely now. Thanks everyone!
[Bug fortran/102862] New: CLASS(*) – various issues, esp. with assumed-rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102862 Bug ID: 102862 Summary: CLASS(*) – various issues, esp. with assumed-rank Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic, rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- The following program runs into various issues with CLASS handling in general and CLASS(*) handling in particular. It compiles when using 'integer' but with 'class(*)' it fails with: assumed-rank-class.f90:19:13: 19 | rank(*) | 1 Error: Array pointer ‘__tmp_class___class__STAR_15_0t_rank_m1’ at (1) must have a deferred shape or assumed rank assumed-rank-class.f90:22:17: 22 | if (any(x(1:10) /= [(i, i=1,10)])) error stop | 1 Error: Operands of comparison operator ‘/=’ at (1) are CLASS(*)/INTEGER(4) assumed-rank-class.f90:5:14: 5 | call caller(A) | 1 Error: Rank mismatch in argument ‘y’ at (1) (rank-3 and rank-1) all of which are bogus. implicit none integer :: i integer :: A(10) A = [(i, i = 1, 10)] call caller(A) contains subroutine caller(y) class(*) :: y(5,-3:6,*) !integer :: y(5,-3:6,*) call foo(y) end subroutine foo(x) class(*) :: x(..) !integer :: x(..) integer :: i print *, rank(x) print *, shape(x) select rank(x) rank(*) print *,rank(x) ! OK - assumed size actual if (any(x(1:10) /= [(i, i=1,10)])) error stop rank default error stop 1 end select end subroutine end
[Bug testsuite/102861] [12 regression] gcc.dg/vect/bb-slp-16.c fails after r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102861 --- Comment #2 from Andrew Pinski --- (In reply to Aldy Hernandez from comment #1) > Similarly to 102860. > > The referenced patch reduces the amount of threaded paths, not increase > them. This actually looks like another pass hiccuping because it was > expecting a threaded path that is no longer there. The commit changed vect/bb-slp-16.c by a lot ...
[Bug target/102860] [12 regression] libgomp.fortran/simd2.f90 ICEs after r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102860 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||ice-on-valid-code
[Bug tree-optimization/102703] [12 Regression] Dead Code Elimination Regression at -O3 since r12-2591-g2e96b5f14e402569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703 --- Comment #16 from Andrew Pinski --- I have a new patch in testing that replaces patch 4 and uses simple_dce_from_worklist instead which moves of the detection of dead code to already common code.
[Bug fortran/102815] gfortran.dg/bind-c-contiguous-5.f90 fails at execution on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102815 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Christophe Lyon --- I confirm it is now fixed, thanks!
[Bug testsuite/102861] [12 regression] gcc.dg/vect/bb-slp-16.c fails after r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102861 --- Comment #1 from Aldy Hernandez --- Similarly to 102860. The referenced patch reduces the amount of threaded paths, not increase them. This actually looks like another pass hiccuping because it was expecting a threaded path that is no longer there.
[Bug target/102860] [12 regression] libgomp.fortran/simd2.f90 ICEs after r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102860 --- Comment #1 from Aldy Hernandez --- The referenced patch reduces the amount of threaded paths, not increase them. This actually looks like another pass hiccuping because it was expecting a threaded path that is no longer there.
[Bug testsuite/102861] New: [12 regression] gcc.dg/vect/bb-slp-16.c fails after r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102861 Bug ID: 102861 Summary: [12 regression] gcc.dg/vect/bb-slp-16.c fails after r12-4526 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:d8edfadfc7a9795b65177a50ce44fd348858e844, r12-4526 make -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/bb-slp-16.c" FAIL: gcc.dg/vect/bb-slp-16.c execution test # of expected passes5 # of unexpected failures1 No messages from the failure: Running /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/vect.exp ... FAIL: gcc.dg/vect/bb-slp-16.c execution test === gcc Summary === # of expected passes5 # of unexpected failures1 Hmmm. Looks like this used to be xfailed. commit d8edfadfc7a9795b65177a50ce44fd348858e844 (HEAD, refs/bisect/bad) Author: Aldy Hernandez Date: Mon Oct 4 09:47:02 2021 +0200 Disallow loop rotation and loop header crossing in jump threaders.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #71 from Óscar Fuentes --- (In reply to Eric Botcazou from comment #70) > Tentatively fixed, reopen if not. The bootstrap works. Thank you.
[Bug target/102860] New: [12 regression] libgomp.fortran/simd2.f90 ICEs after r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102860 Bug ID: 102860 Summary: [12 regression] libgomp.fortran/simd2.f90 ICEs after r12-4526 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:d8edfadfc7a9795b65177a50ce44fd348858e844, r12-4526 I am only seeing this on a power 10 machine. make -k check-target-libgomp RUNTESTFLAGS="fortran.exp=libgomp.fortran/simd2.f90" FAIL: libgomp.fortran/simd2.f90 -O2 (internal compiler error) FAIL: libgomp.fortran/simd2.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/simd2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) FAIL: libgomp.fortran/simd2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: libgomp.fortran/simd2.f90 -O3 -g (internal compiler error) FAIL: libgomp.fortran/simd2.f90 -O3 -g (test for excess errors) # of expected passes6 # of unexpected failures6 # of unresolved testcases 3 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include /home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.fortran/simd2.f90 -B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/../../include -I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp -B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs/ -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs -fintrinsic-modules-path=/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp -L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs -L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs/ -L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs -lgfortran -foffload=-lgfortran -lquadmath -lm -o ./simd2.exe during RTL pass: expand /home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.fortran/simd2.f90:11:30: internal compiler error: in prepare_cmp_insn, at optabs.c:4532 0x10ad438b prepare_cmp_insn /home/seurer/gcc/git/gcc-test/gcc/optabs.c:4532 0x10ad4507 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*, machine_mode, int, rtx_def*, profile_probability) /home/seurer/gcc/git/gcc-test/gcc/optabs.c:4677 0x106346a7 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int, machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, profile_probability) /home/seurer/gcc/git/gcc-test/gcc/dojump.c:1220 0x10712eff do_cmp_and_jump /home/seurer/gcc/git/gcc-test/gcc/expmed.c:6346 0x10712eff expand_divmod(int, tree_code, machine_mode, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) /home/seurer/gcc/git/gcc-test/gcc/expmed.c:4865 0x10716dbb expand_expr_divmod /home/seurer/gcc/git/gcc-test/gcc/expr.c:8945 0x1074094b expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /home/seurer/gcc/git/gcc-test/gcc/expr.c:9582 0x105686a7 expand_gimple_stmt_1 /home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:3979 0x105686a7 expand_gimple_stmt /home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:4040 0x105717db expand_gimple_basic_block /home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:6082 0x1057476b execute /home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:6808 commit d8edfadfc7a9795b65177a50ce44fd348858e844 (HEAD, refs/bisect/bad) Author: Aldy Hernandez Date: Mon Oct 4 09:47:02 2021 +0200 Disallow loop rotation and loop header crossing in jump threaders.
[Bug fortran/102859] New: [OpenMP] Missing testsuite coverage for Fortran task reductions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102859 Bug ID: 102859 Summary: [OpenMP] Missing testsuite coverage for Fortran task reductions Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- From: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579694.html for PR100753 (Fortran part), follow up was https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582015.html (committed) – that added some lightweight test coverage, but still: > If this was missing, then I'm afraid we lack a lot of testsuite coverage for > Fortran task reductions. It doesn't need to be covered in this patch, but > would be > good to cover it incrementally. Because the above means nothing with > taskgroup with task_reduction clause(s) could work properly at runtime. Additionally missing: Array sections in reductions appear to be still not supported by the Fortran FE in general → testcase (for target in_reduction and in general).
[Bug libgomp/100753] Implement in_reduction clause on target construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100753 --- Comment #3 from Tobias Burnus --- (In reply to Tobias Burnus from comment #2) > Additionally missing: Fortran support. Fortran support was implemented in r12-4574-gd98626bf451dea6a28a42d953f7d0bd7659ad4d5 Still to do: Proper nowait support as described above.
[Bug tree-optimization/102844] [9/10/11/12 Regression] DOM jump threading not copying block that became non-empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 --- Comment #23 from Jeffrey A. Law --- Invalid is invalid. Full stop. I'll have to put it under a debugger, but I would have expected the nocopy block to turn into a forwarder -- why do we end up putting statements in here?
[Bug c++/99244] [modules] ICE in tsubst_copy, at cp/pt.c:16581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99244 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-20 Ever confirmed|0 |1 Keywords||ice-on-valid-code --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > This seems to be fixed on trunk. Oops, no it isn't.
[Bug c++/99244] [modules] ICE in tsubst_copy, at cp/pt.c:16581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99244 --- Comment #2 from Jonathan Wakely --- This seems to be fixed on trunk.
[Bug c++/99244] [modules] ICE in tsubst_copy, at cp/pt.c:16581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99244 Jonathan Wakely changed: What|Removed |Added CC||niancw29 at 163 dot com --- Comment #1 from Jonathan Wakely --- *** Bug 102858 has been marked as a duplicate of this bug. ***
[Bug c++/102858] ICE when compiling to "thread.gcm"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102858 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- This is a duplicate. *** This bug has been marked as a duplicate of bug 99244 ***
[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842 --- Comment #9 from tt_1 --- So, I did a little bit of research. pr92807 has indeed been backported to the gcc-10 branch and is included in the gcc-10.3.0 release - it touches gcc/config/i386/i386.c and adds a testcase. There is another fixup on top of that, which is the real fix the here reported ICE: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=74dc179a6da33cd00f6d4a93fbb97dc84f610126 or r11-209-g74dc179a6da33cd00f6d4a93fbb97dc84f610126 , to which you pointed me as the most likely fix. But that fixup (commited by Vladimir Makarov) doesn't have any bug number in the description. I wrote him an email, maybe he will comment here later. Hint: its not an option to upgrade to gcc-11.2.0, since the cross compile bootstrap is fundamentally broken by missing fenv header in the gcc-11 branch. Mixing up host and target compiler versions is nothing to desire, its a place where there will be dragons.
[Bug c++/102820] [DR2351] Failure to compile void{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 51638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51638=edit gcc12-pr102820.patch Untested fix.
[Bug c++/102858] New: ICE when compiling to "thread.gcm"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102858 Bug ID: 102858 Summary: ICE when compiling to "thread.gcm" Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: niancw29 at 163 dot com Target Milestone: --- Created attachment 51637 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51637=edit preprocessed file Target: x86_64-pc-linux-gnu Configured with: ../gcc-11.2.0/configure --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.2.0 (GCC) command: g++ -std=c++20 -fmodules-ts -c -x c++-system-header thread the compiler output: In file included from /usr/local/include/c++/11.2.0/bits/atomic_base.h:38, from /usr/local/include/c++/11.2.0/atomic:41, of module /usr/local/include/c++/11.2.0/atomic, imported at /usr/local/include/c++/11.2.0/stop_token:34, included from /usr/local/include/c++/11.2.0/thread:40: /usr/local/include/c++/11.2.0/bits/move.h: In instantiation of ‘constexpr std::_Require >, std::is_move_constructible<_Tp>, std::is_move_assignable<_Tp> > std::swap(_Tp&, _Tp&) [with _Tp = std::thread::id; std::_Require >, std::is_move_constructible<_Tp>, std::is_move_assignable<_Tp> > = void]’: /usr/local/include/c++/11.2.0/bits/std_thread.h:172:16: required from here /usr/local/include/c++/11.2.0/bits/move.h:204:19: internal compiler error: in tsubst_copy, at cp/pt.c:16621 204 | _Tp __tmp = _GLIBCXX_MOVE(__a); | ^ 0x62699c tsubst_copy ../../gcc-11.2.0/gcc/cp/pt.c:16621 0x7c15ce tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-11.2.0/gcc/cp/pt.c:20782 0x7c1dbb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-11.2.0/gcc/cp/pt.c:19548 0x7c1dbb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-11.2.0/gcc/cp/pt.c:19680 0x7c19bd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-11.2.0/gcc/cp/pt.c:19548 0x7c19bd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-11.2.0/gcc/cp/pt.c:20206 0x7d3124 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-11.2.0/gcc/cp/pt.c:19548 0x7d3124 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-11.2.0/gcc/cp/pt.c:19159 0x7d923c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-11.2.0/gcc/cp/pt.c:16527 0x7d923c tsubst_init ../../gcc-11.2.0/gcc/cp/pt.c:16531 0x7d6121 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-11.2.0/gcc/cp/pt.c:18368 0x7d4d6a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-11.2.0/gcc/cp/pt.c:18184 0x7d4d6a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-11.2.0/gcc/cp/pt.c:18199 0x7d3c5f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-11.2.0/gcc/cp/pt.c:18184 0x7d3c5f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-11.2.0/gcc/cp/pt.c:18550 0x7c7749 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-11.2.0/gcc/cp/pt.c:25876 0x7c7749 instantiate_body ../../gcc-11.2.0/gcc/cp/pt.c:25876 0x7c809f instantiate_decl(tree_node*, bool, bool) ../../gcc-11.2.0/gcc/cp/pt.c:26170 0x7e3cfb instantiate_pending_templates(int) ../../gcc-11.2.0/gcc/cp/pt.c:26249 0x6f5fa8 c_parse_final_cleanups() ../../gcc-11.2.0/gcc/cp/decl2.c:4962
[Bug modula2/102325] gm2 testsuite drivers should be unique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325 David Edelsohn changed: What|Removed |Added Status|NEW |RESOLVED CC||dje at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from David Edelsohn --- Gaius reports fixed.
[Bug modula2/102323] gm2 testsuite needs to be parallelized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102323 David Edelsohn changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||dje at gcc dot gnu.org --- Comment #2 from David Edelsohn --- Gaius reports fixed.
[Bug modula2/102339] gm2 testsuite leaves many files behind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102339 David Edelsohn changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||dje at gcc dot gnu.org --- Comment #3 from David Edelsohn --- Gaius reports fixed.
[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344 David Edelsohn changed: What|Removed |Added Resolution|--- |FIXED CC||dje at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #5 from David Edelsohn --- Gaius reports fixed.
[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Gaius Mulley --- > apologies if this is the wrong way to mention a status change. (Is this > done on bugzilla? I've looked and cannot see how to change its status > :-). The customary way is to change the Status to CONFIRMED once you've verified the report is correct. Once you start working on a fix (or intend to), assign the PR to yourself. When the fix is done and has been committed, change the Status to RESOLVED. Please add a PR reference for the fix to the ChangeLog entry as described in https://gcc.gnu.org/codingconventions.html#ChangeLogs e.g PR modula2/102344 This way, the PR is automatically updated with a reference to the commit. > I'd like to confirm the bug and report that it is now fixed (I believe) in the > git repro. I've moved TestLong4.mod to the pass directory, Thanks. I'll try another build of the branch once I get around to it.
[Bug target/102847] [12 regression] r12-4504 breaks powerpc64 build on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102847 --- Comment #3 from seurer at gcc dot gnu.org --- I reran my bisects on two different systems and both resolved to g:793d2549b173a0a2da6dd20ffc27acb9fd2de73e, r12-4501 as when the builds started failing. r12-4500 worked on both systems.
[Bug modula2/102325] gm2 testsuite drivers should be unique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325 --- Comment #3 from Gaius Mulley --- "rguenth at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325 > > Richard Biener changed: > >What|Removed |Added > >Last reconfirmed||2021-09-14 > Ever confirmed|0 |1 > Status|UNCONFIRMED |NEW > > --- Comment #1 from Richard Biener --- > Confirmed. [again apologies if this is the wrong way to mention a status change.] now fixed in the git repro. regards, Gaius regards, Gaius
[Bug modula2/102339] gm2 testsuite leaves many files behind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102339 --- Comment #2 from Gaius Mulley --- "ro at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102339 > > Bug ID: 102339 >Summary: gm2 testsuite leaves many files behind >Product: gcc >Version: 12.0 > Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: modula2 > Assignee: unassigned at gcc dot gnu.org > Reporter: ro at gcc dot gnu.org > CC: gaiusmod2 at gmail dot com > Target Milestone: --- > > After running the gm2 testsuite, there are almost 2000 files left behind in > gcc/testsuite/gm2. All but a handful follow the same pattern, e.g. > > wr.x0-wr_m2.o > > I suspect this is a driver issue: m2-link-support.h has > > #define SCAFFOLDNAME "%b_m2" > > Since those files are purely temporary, I suspect (but haven't tried) that > they > should be marked as such using %d. > > There are only a few more: > > * remaining objects: > > cpp.o > cvararg.o > fileio.o > hello.o > mycpp.o > rangesupport.o > sys.o > testiotransfer.o > wr.o > > * also: > > integer.x0-integer_m2.cpp > integer.x1-integer_m2.cpp > integer.x2-integer_m2.cpp > integer.x3-integer_m2.cpp > integer.x4-integer_m2.cpp > integer.x5-integer_m2.cpp > > results.dat > > second.txt > > test.txt > > testiotransfer.x2* > testiotransfer.x5* > testtime.x3* [again apologies if this is the wrong way to mention a status change.] I'd like to confirm the bug and report that it is now fixed (I believe) in the git repro. regards, Gaius regards, Gaius
[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344 --- Comment #3 from Gaius Mulley --- "ro at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344 > > Bug ID: 102344 >Summary: gm2/pim/fail/TestLong4.mod FAILs >Product: gcc >Version: 12.0 > Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: modula2 > Assignee: unassigned at gcc dot gnu.org > Reporter: ro at gcc dot gnu.org > CC: gaiusmod2 at gmail dot com > Target Milestone: --- > > The gm2/pim/fail/TestLong4.mod test FAILs everywhere, it seems (seen on > i386-pc-solaris2.11 and x86_64-pc-linux-gnu, both 32 and 64-bit): > > FAIL: gm2/pim/fail/TestLong4.mod, -g > FAIL: gm2/pim/fail/TestLong4.mod, -O > FAIL: gm2/pim/fail/TestLong4.mod, -O -g > FAIL: gm2/pim/fail/TestLong4.mod, -Os > FAIL: gm2/pim/fail/TestLong4.mod, -O3 -fomit-frame-pointer > FAIL: gm2/pim/fail/TestLong4.mod, -O3 -fomit-frame-pointer -finline-functions > > The test is expected to FAIL, it seems, but actually compilation completes > without error. So this should actually be an XPASS instead. apologies if this is the wrong way to mention a status change. (Is this done on bugzilla? I've looked and cannot see how to change its status :-). I'd like to confirm the bug and report that it is now fixed (I believe) in the git repro. I've moved TestLong4.mod to the pass directory, regards, Gaius regards, Gaius
[Bug middle-end/102857] [12 regression] r12-4526 caused regressions on vect/bb-slp-16.c and ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Jakub Jelinek --- > Does the committed patch fix the issue on Solaris? I'll see after tonight's bootstrap. The original one attached to the PR fixed only a few of the failures: -FAIL: libgomp.c/../libgomp.c-c++-common/for-1.c execution test -FAIL: libgomp.c/../libgomp.c-c++-common/for-2.c execution test -FAIL: libgomp.c/../libgomp.c-c++-common/for-7.c execution test -FAIL: libgomp.c/../libgomp.c-c++-common/for-8.c execution test
[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838 --- Comment #5 from Jakub Jelinek --- Does the committed patch fix the issue on Solaris?
[Bug libstdc++/98005] FAIL: std/ranges/adaptors/sizeof.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98005 --- Comment #7 from Patrick Palka --- Looks like after r12-4517 the test now compiles successfully on m68k according to https://gcc.gnu.org/pipermail/gcc-testresults/2021-October/729689.html Though the test presumably still fails on the 11 branch.
[Bug c++/91118] ubsan does not work with openmp default (none) directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91118 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug target/102374] [x86_64] Should ignore spaces in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102374 Martin Liška changed: What|Removed |Added Resolution|FIXED |WONTFIX --- Comment #4 from Martin Liška --- Reverted based on the discussion in PR102375.
[Bug tree-optimization/102844] [9/10/11/12 Regression] DOM jump threading not copying block that became non-empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 --- Comment #22 from Andrew Macleod --- (In reply to Richard Biener from comment #20) > (In reply to Aldy Hernandez from comment #18) > > (In reply to rguent...@suse.de from comment #17) > > > On Wed, 20 Oct 2021, aldyh at gcc dot gnu.org wrote: > > > > > > Silly question, why is the SSA form invalid on entry to VRP2? That's > > > > just > > > > asking for trouble. Is this related to how asserts work? > > > > > > Well, DOM threading creates invalid SSA (definition not dominating use). > > > Doesn't have to do anything with VRP or asserts. > > > > Ah, I see. > > > > BTW, if this is still the case in mainline, this is bound to be a problem > > for the ranger. Andrew, won't we get an UNDEFINED / unreachable if we query > > the non dominating use at this point? > > Well, invalid IL is invalid - there's no need to "cope" with it. We have to > fix the (forward) threading code. Indeed, invalid is invalid. And it depends. Any on-entry range is the union of all incoming blocks. If we query a use that has no def anywhere in the dominator tree , then you will get UNDEFINED. If the def is on at least one incoming path, then you will get the def or some derivative of it.
[Bug target/102375] [aarch64] Should allow space in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375 Martin Liška changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #12 from Martin Liška --- All right, let me revert my patches then..
[Bug target/102375] [aarch64] Should allow space in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375 --- Comment #11 from Jakub Jelinek --- BTW, if we want to use strip_whitespaces, it should use ISBLANK or ISSPACE instead of using == ' ' or == '\t' etc. comparisons. But I really find it not a good idea to support "\t\t+sve\t\t " (or similarly on x86).
[Bug target/100966] [AArch64] __builtin_roundeven[f] is not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100966 Wilco changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #2 from Wilco --- Fixed
[Bug middle-end/102857] New: [12 regression] r12-4526 caused regressions on vect/bb-slp-16.c and ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 Bug ID: 102857 Summary: [12 regression] r12-4526 caused regressions on vect/bb-slp-16.c and ssa-dom-thread-7.c Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- r12-4526 (g:d8edfadfc7a9795b65177a50ce44fd348858e844) caused regressions. On aarch64 and arm-none-linux-gnueabihf with-arch armv7-a+mp+sec+neon-fp16 FAIL: gcc.dg/vect/bb-slp-16.c execution test On both aarch64/arm FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps threaded: 12" On arm-none-linux-gnueabihf --with-arch armv7-a+mp+sec+neon-fp16 FAIL: gcc.target/arm/ivopts-4.c object-size text <= 36 The last one is very fragile and depends on the actual target/flags.
[Bug target/100966] [AArch64] __builtin_roundeven[f] is not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100966 --- Comment #1 from CVS Commits --- The master branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:16ce822ed14e6635ee2ffcba394bba8e934bc6dd commit r12-4567-g16ce822ed14e6635ee2ffcba394bba8e934bc6dd Author: Wilco Dijkstra Date: Wed Oct 20 13:09:30 2021 +0100 AArch64: Add support for __builtin_roundeven[f] (PR100966) Enable __builtin_roundeven[f] by changing existing frintn to roundeven. 2021-10-20 Wilco Dijkstra gcc/ PR target/100966 * config/aarch64/aarch64.md (frint_pattern): Update comment. * config/aarch64/aarch64-simd-builtins.def: Change frintn to roundeven. * config/aarch64/arm_fp16.h: Change frintn to roundeven. * config/aarch64/arm_neon.h: Likewise. * config/aarch64/iterators.md (frint_pattern): Use roundeven for FRINTN. gcc/testsuite/ PR target/100966 * gcc.target/aarch64/frint.x: Add roundeven tests. * gcc.target/aarch64/frint_double.c: Likewise. * gcc.target/aarch64/frint_float.c: Likewise.
[Bug testsuite/102841] [12 regression] libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102841 Rainer Orth changed: What|Removed |Added Summary|libgomp.oacc-c++/../libgomp |[12 regression] |.oacc-c-c++-common/host_dat |libgomp.oacc-c++/../libgomp |a-7.c FAILs |.oacc-c-c++-common/host_dat ||a-7.c FAILs Target|i?86-pc-solaris2.11,|*-*-solaris2.11, |x86_64-pc-solaris2.11, |i?86-apple-darwin*, |i?86-apple-darwin*, |x86_64-apple-darwin* |x86_64-apple-darwin*| --- Comment #2 from Rainer Orth --- (In reply to Thomas Schwinge from comment #1) > (In reply to Rainer Orth from comment #0) > > The libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c has been > > FAILing > > on Solaris and Darwin since it was installed. > > Probably not since it was originally added in commit > d5c23c6ceacf666f218676b648801379044e326a 'OpenACC – support "if" + > "if_present" clauses with "host_data"', but rather in my more recentish > commit 11b8286a83289f5b54e813f14ff56d730c3f3185 "[OpenACC privatization] > Largely extend diagnostics and corresponding testsuite coverage [PR90115]". > (Or, if it indeed has been FAILing before, then it must be a different > problem.) Right, I didn't look closely enough. In fact, the test is PASSing on the gcc-11 branch,so this is even a regression. Besides, it affects Solaris/SPARC and x86 alike, so is not x86-specific. > > On Solaris, the excess errors are > > > [...]: note: variable 'iftmp.3' declared in block isn't candidate for > > adjusting OpenACC privatization level: not addressable > > > while Darwin shows > > > [...]: note: variable 'D.3648' declared in block isn't candidate for > > adjusting OpenACC privatization level: not addressable > > Please do tell if there are further such "[is/isn't] candidate for adjusting > OpenACC privatization level" diagnostic mismatches (excess errors, or > FAILs), in other testcases. (But indeed per a quick scan of > posts, it's just > 'libgomp.oacc-c-c++-common/host_data-7.c', and it PASSed before my > "diagnostics" commit.) No, this is the only instance.
[Bug target/102856] New: [nvptx] Misaligned accesses with cheap vectorization enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102856 Bug ID: 102856 Summary: [nvptx] Misaligned accesses with cheap vectorization enabled Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jules at gcc dot gnu.org Target Milestone: --- Since revision 2b8453c401b699ed93c085d0413ab4b5030bcdb8 I am seeing several OpenMP tests fail with misaligned access errors: PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-11.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-12.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-16.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-3.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-5.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-6.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-9.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-11.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-12.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-16.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-3.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-5.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-6.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-9.c execution test These look like, e.g.: $ ./for-11.exe libgomp: cuCtxSynchronize error: misaligned address libgomp: cuMemFree_v2 error: misaligned address libgomp: device finalization failed I suspect the reason is that an operation that is now being vectorized (e.g. "st.v2.u64 [%frame], %r28;") requires higher alignment than the original scalar accesses it replaces. I haven't spotted an obvious culprit for the problem in the nvptx backend. This is OpenMP, so it could be the soft stack handling -- or it could be something else.
[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842 --- Comment #8 from Martin Liška --- (In reply to tt_1 from comment #7) > hey, thanks for the messages. I just finished to compile firefox with > patched cross-gcc-10.3.0, the ice is fixed with the patch from > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git; > h=74dc179a6da33cd00f6d4a93fbb97dc84f610126 applied to it. Great! > > So can you please tell me if this has already been backported to the gcc-10 > branch? No, it wasn't. > I just browsed through the git dirs, and I'm not certain. Also no > hint in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92807 that its been > fixed for the gcc-10 branch. > > Is it queued to be backported? Apparently, the commit does not fix a regression so the author decided not to backport it. So I would recommend updating to GCC 11.2.0, which is the latest support release. > Sorry if I'm asking dumb questions, I'm just > a regular user, not a gentoo dev. No, your questions are very reasonable and we thank you reporting the issue you deal with.
[Bug tree-optimization/102853] [12 Regression] ICE in compute_distributive_range, at tree-data-ref.c:593 since r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/102853] [12 Regression] ICE in compute_distributive_range, at tree-data-ref.c:593 since r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ac5e46563817f4f1bd786be1d21b85d18e61bc0c commit r12-4558-gac5e46563817f4f1bd786be1d21b85d18e61bc0c Author: Richard Biener Date: Wed Oct 20 12:54:59 2021 +0200 tree-optimization/102853 - avoid trapping types in split_constant_offset This avoids running into the assert in compute_distributive_range when starting the analysis with operations in a trapping type. 2021-10-20 Richard Biener PR tree-optimization/102853 * tree-data-ref.c (split_constant_offset_1): Bail out immediately if the expression traps on overflow.
[Bug c++/102854] [OpenMP] Bogus "initializer expression refers to iteration variable" when using templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102854 --- Comment #1 from Tobias Burnus --- For the non-template case (with int / IndexType reversed, (ups!)): finish_omp_for's vec *orig_inits is an empty vector but for the template, it isn't (it contains '0' and 'i'); thus, the following check is run and fails: FOR_EACH_VEC_ELT (*orig_inits, i, orig_init) if (orig_init && !c_omp_check_loop_iv_exprs (locus, The reason is that type_dependent_expression_p (decl) == true in cp_parser_omp_for_loop_init.
[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842 --- Comment #7 from tt_1 --- hey, thanks for the messages. I just finished to compile firefox with patched cross-gcc-10.3.0, the ice is fixed with the patch from https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=74dc179a6da33cd00f6d4a93fbb97dc84f610126 applied to it. So can you please tell me if this has already been backported to the gcc-10 branch? I just browsed through the git dirs, and I'm not certain. Also no hint in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92807 that its been fixed for the gcc-10 branch. Is it queued to be backported? Sorry if I'm asking dumb questions, I'm just a regular user, not a gentoo dev.
[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757 --- Comment #15 from Christophe Lyon --- Hi, yes this is close to completion. The patch series was approved last week by Richard Sandiford: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581778.html but I have found a bug with more validations, I'm discussing the fix with him, should be ready shortly.
[Bug c++/102855] #pragma GCC unroll n should support n being a template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102855 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-10-20 Severity|normal |enhancement Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 --- Comment #21 from Martin Liška --- (In reply to Richard Biener from comment #12) > (In reply to Martin Liška from comment #10) > > (In reply to Richard Biener from comment #9) > > > (In reply to Martin Liška from comment #8) > > > > Using x86_64 compiler, the issue is fixed on master after > > > > r10-1420-g744fd446c321f78f and started with r9-6384-g1a438d160e1dc845. > > > > > > Can you continue searching for a fix with -fdisable-tree-fre4 (r10-1420 > > > added FRE4 before DOM3). > > > > Sure, then it gets fixed with r11-408-g84935c9822183ce4. > > -fno-tree-sink? This is fixed with r11-4637-gf5e18dd9c7dacc96.
[Bug tree-optimization/102853] [12 Regression] ICE in compute_distributive_range, at tree-data-ref.c:593 since r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853 --- Comment #3 from rguenther at suse dot de --- On Wed, 20 Oct 2021, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853 > > --- Comment #2 from rsandifo at gcc dot gnu.org > --- > Maybe it's much of a muchness, but would it work instead to bail > out for wrapping types at the top of split_constant_offset_1 > and remove the check for trapping from the CASE_CONVERT code? > It seems that in practice split_constant_offset_1 can't handle > any trapping types. Yeah, that makes sense.
[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Martin Liška --- Closing as fixed.
[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842
--- Comment #5 from Martin Liška ---
And reduced test-case looks like this:
struct Plane {
using T = float;
T *Row();
};
using ImageF = Plane;
long long Mirror_x;
struct EnsurePaddingInPlaceRowByRow {
void Process() {
switch (strategy_) {
case kSlow:
float *row = img_.Row();
long long xsize = x1_;
while (Mirror_x >= xsize)
if (Mirror_x)
Mirror_x = 2 * xsize - 1;
*row = Mirror_x;
}
}
ImageF img_;
unsigned x1_;
enum { kSlow } strategy_;
};
void FinalizeImageRect() {
EnsurePaddingInPlaceRowByRow ensure_padding;
ensure_padding.Process();
}
[Bug middle-end/64888] ubsan doesn't work with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Created attachment 51636 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51636=edit gcc12-pr64888.patch Untested fix.
[Bug target/102375] [aarch64] Should allow space in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375
--- Comment #10 from Jonathan Wakely ---
You can also use string literal concatenation:
target("foo," "bar," "baz") which is identical to target("foo,bar,baz")
Although target("foo", "bar", "baz") seems easier to read anyway.
[Bug tree-optimization/102853] [12 Regression] ICE in compute_distributive_range, at tree-data-ref.c:593 since r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853 --- Comment #2 from rsandifo at gcc dot gnu.org --- Maybe it's much of a muchness, but would it work instead to bail out for wrapping types at the top of split_constant_offset_1 and remove the check for trapping from the CASE_CONVERT code? It seems that in practice split_constant_offset_1 can't handle any trapping types.
[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #14 from vvinayag at arm dot com --- (In reply to Christophe Lyon from comment #12) > Yes, I've been working on it for a while, it's proving to be a bit tricky > when switching to HImode as suggested by Richard. I have something working, > now checking I haven't broken Neon. Hi Christophe, if you are working on this, just wondering whether we are close to getting a patch for this, thank you.
[Bug tree-optimization/102853] [12 Regression] ICE in compute_distributive_range, at tree-data-ref.c:593 since r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Target|ppc64-linux-gnu |ppc64-linux-gnu, ||powerpc64le-linux-gnu Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org CC||rsandifo at gcc dot gnu.org --- Comment #1 from Richard Biener --- Also on LE, even without -mmodulo. Richard inserted the assert with the last refactoring of split_constant_offset. We are splitting the initial value of the IV tmp.9_69 here which is niters_vector_mult_vf.8_68 = bnd.7_67 << 3; _70 = (long int) niters_vector_mult_vf.8_68; _71 = _70 * 2; tmp.9_69 = buf_12(D) + _71; and the operation we're asserting on is _70 * 2. Note the IV is (short int *) buf_53 with # buf_53 = PHI <..., tmp9_69> so the trigger for the ICE is the added 1373 STRIP_NOPS (access_fn); in dr_analyze_indices. That was necessary to avoid regressions when IVs are demoted to uintptr_t by if-conversion. split_constant_offset makes sure to not look through conversions to trapping types - maybe that check should also be on the individual operations in case we start analyzing with an expression in trapping types (as done here)? Immediate mitigation would of course be to restrict the STRIP_NOPS to not expose an IV that evolves in a trapping type. For example the following would fix it: diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c index 57bac06242f..2cae2528e41 100644 --- a/gcc/tree-data-ref.c +++ b/gcc/tree-data-ref.c @@ -775,6 +775,9 @@ split_constant_offset_1 (tree type, tree op0, enum tree_code code, tree op1, case PLUS_EXPR: case MINUS_EXPR: + if (TYPE_OVERFLOW_TRAPS (type)) + return false; + split_constant_offset (op0, , , _range, cache, limit); split_constant_offset (op1, , , _range, cache, limit); *off = size_binop (code, off0, off1); @@ -785,7 +788,7 @@ split_constant_offset_1 (tree type, tree op0, enum tree_code code, tree op1, return true; case MULT_EXPR: - if (TREE_CODE (op1) != INTEGER_CST) + if (TREE_CODE (op1) != INTEGER_CST || TYPE_OVERFLOW_TRAPS (type)) return false; split_constant_offset (op0, , , _range, cache, limit); of course (after more work already done), compute_distributive_range could return false itself. Richard?
[Bug c++/102855] New: #pragma GCC unroll n should support n being a template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102855
Bug ID: 102855
Summary: #pragma GCC unroll n should support n being a template
parameter
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernhardmgruber at gmail dot com
Target Milestone: ---
Using `#pragma GCC unroll n` for a loop fails to compile when `n` is a template
parameter. Given the following code:
```c++
void f(int);
template
void g() {
#pragma GCC unroll n
for (int i = 0; i < n; i++)
f(i);
}
int main() {
constexpr auto n = 100;
g();
}
```
g++-11.2 produces the following diagnostic:
```
source>: In function 'void g()':
:5:24: error: '#pragma GCC unroll' requires an assignment-expression
that evaluates to a non-negative integral constant less than 65535
5 | #pragma GCC unroll n
|^
```
If `g` is turned into a normal function and the variable `n` is moved form
`main` to `g`, the example compiles fine and produces the expected behavior.
Allowing `n` inside the pragma to be a template parameter helps temendously in
optimizing hot loops in templated numeric codes. Such a feature is also
supported by clang, icc and nvcc. I want to kindly ask you to provide this
additional functionality.
Thank you!
Example on godbolt:
https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:2,endLineNumber:8,positionColumn:2,positionLineNumber:8,selectionStartColumn:2,selectionStartLineNumber:8,startColumn:2,startLineNumber:8),source:'void+f(int)%3B%0A%0Atemplate+%3Cint+n%3E%0Avoid+g()+%7B%0A%23pragma+GCC+unroll+n%0Afor+(int+i+%3D+0%3B+i+%3C+n%3B+i%2B%2B)%0Af(i)%3B%0A%7D%0A%0Aint+main()+%7B%0Aconstexpr+auto+n+%3D+100%3B%0Ag%3Cn%3E()%3B%0A%7D'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:54.105263157894754,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((g:!((h:compiler,i:(compiler:g112,filters:(b:'0',binary:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'0',trim:'1'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:4,lang:c%2B%2B,libs:!(),options:'-O3+-Wall+-Wextra',selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1,tree:'1'),l:'5',n:'0',o:'x86-64+gcc+11.2+(C%2B%2B,+Editor+%231,+Compiler+%234)',t:'0')),k:20.004,l:'4',m:50,n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compiler:4,editor:1,fontScale:14,fontUsePx:'0',tree:'1',wrap:'1'),l:'5',n:'0',o:'Output+of+x86-64+gcc+11.2+(Compiler+%234)',t:'0')),header:(),l:'4',m:50,n:'0',o:'',s:0,t:'0')),k:45.894736842105274,l:'3',n:'0',o:'',t:'0')),l:'2',n:'0',o:'',t:'0')),version:4
[Bug target/102375] [aarch64] Should allow space in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375
--- Comment #9 from Jakub Jelinek ---
And note we already do support target ("+sve", "+sve2"), so there is not much
point in allowing whitespace inside of the string literals.
[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 --- Comment #20 from Richard Biener --- (In reply to Aldy Hernandez from comment #18) > (In reply to rguent...@suse.de from comment #17) > > On Wed, 20 Oct 2021, aldyh at gcc dot gnu.org wrote: > > > > Silly question, why is the SSA form invalid on entry to VRP2? That's just > > > asking for trouble. Is this related to how asserts work? > > > > Well, DOM threading creates invalid SSA (definition not dominating use). > > Doesn't have to do anything with VRP or asserts. > > Ah, I see. > > BTW, if this is still the case in mainline, this is bound to be a problem > for the ranger. Andrew, won't we get an UNDEFINED / unreachable if we query > the non dominating use at this point? Well, invalid IL is invalid - there's no need to "cope" with it. We have to fix the (forward) threading code.
[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Status|ASSIGNED|NEW Priority|P3 |P2 Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #19 from Richard Biener --- (In reply to Richard Biener from comment #15) > The following removes the premature optimization(?) using > EDGE_NO_COPY_SRC_BLOCK > in case the block contained a condition we could thread through. That fixes > the testcase. > > diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c > index c3ea2d680d8..2005e30322b 100644 > --- a/gcc/tree-ssa-threadedge.c > +++ b/gcc/tree-ssa-threadedge.c > @@ -989,8 +989,11 @@ thread_around_empty_blocks (edge taken_edge, > return false; >bitmap_set_bit (visited, taken_edge->dest->index); > > + /* We may not use EDGE_NO_COPY_SRC_BLOCK since the condition > +might later be simplified to something needing a temporary > +SSA definition. See PR102844. */ >jump_thread_edge *x > - = new jump_thread_edge (taken_edge, EDGE_NO_COPY_SRC_BLOCK); > + = new jump_thread_edge (taken_edge, EDGE_COPY_SRC_BLOCK); >path->safe_push (x); > >thread_around_empty_blocks (taken_edge, OK, it isn't that easy - we overrun redirection_data::dup_blocks that way causing random crashes later on. So the change needs adjustments to how we account thread_around_empty_blocks stuff, I couldn't find the code that avoids this for non-empty blocks. The issue is definitely latent everywhere even trunk as long as we keep the DOM forward threader there.
[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #18 from Aldy Hernandez --- (In reply to rguent...@suse.de from comment #17) > On Wed, 20 Oct 2021, aldyh at gcc dot gnu.org wrote: > > Silly question, why is the SSA form invalid on entry to VRP2? That's just > > asking for trouble. Is this related to how asserts work? > > Well, DOM threading creates invalid SSA (definition not dominating use). > Doesn't have to do anything with VRP or asserts. Ah, I see. BTW, if this is still the case in mainline, this is bound to be a problem for the ranger. Andrew, won't we get an UNDEFINED / unreachable if we query the non dominating use at this point?
[Bug c++/102854] New: [OpenMP] Bogus "initializer expression refers to iteration variable" when using templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102854
Bug ID: 102854
Summary: [OpenMP] Bogus "initializer expression refers to
iteration variable" when using templates
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: openmp, rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
The following code compiles with the "typedef" but fails when used as
"template" with:
fooc.c:9:3: error: initializer expression refers to iteration variable ‘i’
9 | for (IndexType i = 0; i < N; ++i)
| ^~~
Long version:
https://github.com/SOLLVE/sollve_vv/blob/master/tests/5.0/application_kernels/lsms_triangular_packing.cpp
[Side note: According to the notes in the Pull Request #225, it works with LLVM
13 but fails with LLVM 11 and 12.]
Reduceted testcase:
// typedef IndexType int; // < works:
template // < fails
void
foo (IndexType N, IndexType M)
{
#pragma omp target teams distribute parallel for collapse(2)
for (IndexType i = 0; i < N; ++i)
for (IndexType k = i; k < M; ++k)
;
}
[Bug target/102375] [aarch64] Should allow space in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375 --- Comment #8 from Jakub Jelinek --- Or yet another variant is only allow whitespace after , separator and not anywhere else, so "+sve, +sve2" is ok, but "+sve, +sve2" is not. But again, if we decide to do that, it should be done on all targets and not just on one of them, should be done for both target attribute, optimize attribute and pragmas and should be documented.
[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 --- Comment #17 from rguenther at suse dot de --- On Wed, 20 Oct 2021, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 > > --- Comment #16 from Aldy Hernandez --- > (In reply to Richard Biener from comment #13) > > Aldyh might also have stumbled over code avoiding to thread across a SSA > > definition. > > > > Ah - I guess the block is recorded as "forwarder" (block with just a > > condition > > we are able to thread through) but it becomes a non-"forwarder" because > > later > > a SSA definition is inserted but the actual threading code will not copy > > those stmts (or verify they impose no problem)? > > I haven't run into this in the forward threader, but I have run into something > similar in the new path solver (which I fixed). But that's unlikely to help > you here. > > Silly question, why is the SSA form invalid on entry to VRP2? That's just > asking for trouble. Is this related to how asserts work? Well, DOM threading creates invalid SSA (definition not dominating use). Doesn't have to do anything with VRP or asserts.
[Bug target/102375] [aarch64] Should allow space in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375 --- Comment #7 from Jakub Jelinek --- Not allowing spaces there was intentional and has been discussed, please see the https://gcc.gnu.org/legacy-ml/gcc-patches/2019-04/msg00680.html and surrounding threads. As I wrote, if we accept whitespace, it should be done in all places and for all targets, consistency is even more important than whether we allow it or disallow it. So, from this point of view, the r12-4503 change is wrong.
[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 --- Comment #16 from Aldy Hernandez --- (In reply to Richard Biener from comment #13) > Aldyh might also have stumbled over code avoiding to thread across a SSA > definition. > > Ah - I guess the block is recorded as "forwarder" (block with just a > condition > we are able to thread through) but it becomes a non-"forwarder" because later > a SSA definition is inserted but the actual threading code will not copy > those stmts (or verify they impose no problem)? I haven't run into this in the forward threader, but I have run into something similar in the new path solver (which I fixed). But that's unlikely to help you here. Silly question, why is the SSA form invalid on entry to VRP2? That's just asking for trouble. Is this related to how asserts work?
[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 --- Comment #15 from Richard Biener --- The following removes the premature optimization(?) using EDGE_NO_COPY_SRC_BLOCK in case the block contained a condition we could thread through. That fixes the testcase. diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c index c3ea2d680d8..2005e30322b 100644 --- a/gcc/tree-ssa-threadedge.c +++ b/gcc/tree-ssa-threadedge.c @@ -989,8 +989,11 @@ thread_around_empty_blocks (edge taken_edge, return false; bitmap_set_bit (visited, taken_edge->dest->index); + /* We may not use EDGE_NO_COPY_SRC_BLOCK since the condition +might later be simplified to something needing a temporary +SSA definition. See PR102844. */ jump_thread_edge *x - = new jump_thread_edge (taken_edge, EDGE_NO_COPY_SRC_BLOCK); + = new jump_thread_edge (taken_edge, EDGE_COPY_SRC_BLOCK); path->safe_push (x); thread_around_empty_blocks (taken_edge,
[Bug tree-optimization/102814] [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Aldy Hernandez --- fixed
[Bug tree-optimization/102814] [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814 --- Comment #5 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:82cd78f2c31db1664ca154d7fcd24e9eaee1427f commit r12-4532-g82cd78f2c31db1664ca154d7fcd24e9eaee1427f Author: Aldy Hernandez Date: Wed Oct 20 09:05:23 2021 +0200 Restore --param=max-fsm-thread-length The removal of --param=max-fsm-thread-length is causing code explosion. I thought that --param=max-fsm-thread-path-insns was a better gague for path profitability than raw BB length, but it turns out that we don't take into account PHIs when estimating the number of statements. In this PR, we have a sequence of very large PHIs that have us traversing extremely large paths that blow up the compilation. We could fix this a couple of different ways. We could avoid traversing more than a certain number of PHI arguments, or ignore large PHIs altogether. The old implementation certainly had this knob, and we could cut things off before we even got to the ranger. We could also adjust the instruction estimation to take into account PHIs, but I'm sure we'll mess something else in the process ;-). The easiest thing to do is just restore the knob. At a later time we could tweak this further, for instance, disregarding empty blocks in the count. BTW, this is the reason I didn't chop things off in the lowlevel registry for all threaders: the forward threader can't really explore too deep paths, but it could theoretically get there while threading over empty blocks. This fixes 102814, 102852, and I bet it solves the Linux kernel cross compile issue. Tested on x86-64 Linux. gcc/ChangeLog: PR tree-optimization/102814 * doc/invoke.texi: Document --param=max-fsm-thread-length. * params.opt: Add --param=max-fsm-thread-length. * tree-ssa-threadbackward.c (back_threader_profitability::profitable_path_p): Fail on paths longer than max-fsm-thread-length.
