[Bug tree-optimization/107006] Missing optimization: common idiom for external data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006
Richard Biener changed:
What|Removed |Added
Component|rtl-optimization|tree-optimization
Last reconfirmed||2022-09-22
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||missed-optimization
--- Comment #10 from Richard Biener ---
The reason is that the loops are not unrolled (early enough or at all) for the
bswap/load detection. So to work you have to unroll the loops manually or
direct GCC to do that, for example
inline uint64_t get_le64 (const unsigned char x[64/8]) {
uint64_t y = 0;
#pragma GCC unroll 8
for (size_t i = 0; i < sizeof y; i++)
if (0) y |= (uint64_t)x[i] << ((sizeof y - 1 - i)*8);
else y |= (uint64_t)x[i] << i*8; return y;
}
produces
get_le64:
.LFB11:
.cfi_startproc
movq(%rdi), %rax
ret
the unroll heuristics do not anticipate that later bswap/load detection will
merge all the loads and thus not grow code too much.
[Bug target/106910] roundss not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106910 --- Comment #12 from Pilar Latiesa --- Wouldn't it make sense for scalar and vector versions to be affected by the same options?
[Bug target/106910] roundss not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106910 --- Comment #13 from Hongtao.liu --- (In reply to Pilar Latiesa from comment #12) > Wouldn't it make sense for scalar and vector versions to be affected by the > same options? I guess the reason is we don't have __builtin_floorf for vector version, and that option is only apply to direct call for builtin function. I'm not sure should we apply that to internal fn either(to make vector version behave the same as scalar version).
[Bug driver/107007] New: libiberty's win32_spawn error handling is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107007
Bug ID: 107007
Summary: libiberty's win32_spawn error handling is poor
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Host: *-*-mingw*
As described in
https://gcc.gnu.org/pipermail/gcc-help/2022-September/141906.html the
pex_win32_exec_child function just assumes that all errors are ENOENT:
/* Create the child process. */
pid = win32_spawn (executable, (flags & PEX_SEARCH) != 0,
argv, env, dwCreationFlags, &si, &pi);
if (pid == (pid_t) -1)
pid = spawn_script (executable, argv, env, dwCreationFlags,
&si, &pi);
if (pid == (pid_t) -1)
{
*err = ENOENT;
*errmsg = "CreateProcess";
}
This gives users incorrect information when something goes wrong for a reason
that isn't "No such file or directory".
Maybe win32_spawn should use the Win32 GetLastError() function to get a Windows
Error Code and then translate that to an errno value, and store it in errno. Or
ensure that GetLastError will still be valid for the caller of win32_spawn and
spawn_script to retrieve.
libstdc++-v3/src/c++11/system_error.cc already has code to do that translation
(so maybe it should move to libiberty, and then reuse that in libstdc++).
[Bug target/106919] [13 Regression] RTL check: expected code 'set' or 'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919
Matthias Klose changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Matthias Klose ---
$ cat libgcov-merge.i
int __gcov_merge_topn_n_counters;
long __gcov_merge_topn___trans_tmp_1;
void __gcov_merge_topn() {
for (unsigned i = 0; i < __gcov_merge_topn_n_counters / 3; i++) {
for (unsigned j ; __gcov_merge_topn___trans_tmp_1; )
;
}
}
doko@zelenka:~/gcc-snapshot-20220920$ cat libgcov-merge.i
int __gcov_merge_topn_n_counters;
long __gcov_merge_topn___trans_tmp_1;
void __gcov_merge_topn() {
for (unsigned i = 0; i < __gcov_merge_topn_n_counters / 3; i++)
for (; __gcov_merge_topn___trans_tmp_1;)
;
}
$ /home/doko/gcc-snapshot-20220920/build/gcc/xgcc
-B/home/doko/gcc-snapshot-20220920/build/gcc/ -c -march=z196 -m64 -mzarch -g
-O2 libgcov-merge.i libgcov-merge.i
during RTL pass: ce2
libgcov-merge.i: In function '__gcov_merge_topn':
libgcov-merge.i:7:1: internal compiler error: RTL check: expected code 'set' or
'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672
7 | }
| ^
0x22c196b rtl_check_failed_code2(rtx_def const*, rtx_code, rtx_code, char
const*, int, char const*)
../../src/gcc/rtl.cc:926
0x2af1f69 s390_rtx_costs
../../src/gcc/config/s390/s390.cc:3672
0x22e9ab9 rtx_cost(rtx_def*, machine_mode, rtx_code, int, bool)
../../src/gcc/rtlanal.cc:4601
0x22c3877 set_rtx_cost
../../src/gcc/rtl.h:2925
0x22f3eb5 seq_cost(rtx_insn const*, bool)
../../src/gcc/rtlanal.cc:5788
0x38ea2b5 default_noce_conversion_profitable_p(rtx_insn*, noce_if_info*)
../../src/gcc/ifcvt.cc:814
0x38f145f noce_try_cmove
../../src/gcc/ifcvt.cc:1864
0x38fc6d9 noce_process_if_block
../../src/gcc/ifcvt.cc:3964
0x38fe8b5 noce_find_if_block
../../src/gcc/ifcvt.cc:4521
0x38ff33b find_if_header
../../src/gcc/ifcvt.cc:4726
0x3903475 if_convert
../../src/gcc/ifcvt.cc:5873
0x390394d execute
../../src/gcc/ifcvt.cc:6026
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
[Bug target/106919] [13 Regression] RTL check: expected code 'set' or 'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919 --- Comment #3 from Matthias Klose --- rechecked with 20220920
[Bug target/106919] [13 Regression] RTL check: expected code 'set' or 'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919 --- Comment #4 from Matthias Klose --- Created attachment 53611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53611&action=edit preprocessed source
[Bug driver/45749] Response file unwrapped between collect2.exe and ld.exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107007 --- Comment #14 from Jonathan Wakely --- (In reply to Ted from comment #0) > collect2: CreateProcess: No such file or directory > > Which is the typically unhelpful way for Windows to report this problem and > something that led me on a 4 day goose-chase looking for the "missing" file > or directory. GCC is to blame here, not Windows. See PR 107007 for a suggestion how to improve it.
[Bug libstdc++/107008] New: Combine config/os/*/error_constants.h into one file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107008
Bug ID: 107008
Summary: Combine config/os/*/error_constants.h into one file
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
There's no reason to have multiple files and select one for the target:
config/os/djgpp/error_constants.h
config/os/generic/error_constants.h
config/os/mingw32-w64/error_constants.h
config/os/mingw32/error_constants.h
We can just ensure the generic one has a #ifdef for every errno macro that
isn't present on all targets, and use that everywhere.
Once we only have one error_constants.h file for all targets, we can also make
it work for freestanding like so:
#if _GLIBCXX_HOSTED
#include
namespace std {
enum class errc
{
address_family_not_supported =EAFNOSUPPORT,
address_in_use = EADDRINUSE,
// ...
};
}
#else
namespace std {
// For freestanding we have no but also no errors from the OS,
// so we can just make up our own values for the library's purposes.
enum class errc
{
address_family_not_supported = 1,
address_in_use,
// ...
};
}
#endif
This will allow a freestanding to use std::errc.
[Bug libstdc++/107008] Combine config/os/*/error_constants.h into one file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107008
--- Comment #1 from Jonathan Wakely ---
In theory the existing per-target error_constants.h allows an out-of-tree port
for a new OS to use its own error_constants.h more easily. Meh. They would
still need to edit configure.host to overrride ${error_constants_dir}, so they
can just edit the error_constants.h file instead. Adding a couple of #ifdef
conditions in there seems easier than providing a whole new file anyway.
[Bug libstdc++/107008] Combine config/os/*/error_constants.h into one file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107008 --- Comment #2 from Jonathan Wakely --- A related topic is that we simply don't define the errc enumerators that don't have a corresponding E macro, which is non-conforming. The C++ standard says the enumerators should all be there. We could do something like this for each enumerator: #ifdef EFOO foo = EFOO, #else foo = _GLIBCXX_ERRC_ORIGIN + __LINE__, #endif Where _GLIBCXX_ERRC_ORIGIN is some value intended to be higher than the highest errno value on the OS. We only need fewer than 100 errc enumerators so INT_MAX/2 might be OK. We can use #line to set the __LINE__ to a fixed value in the file, so that the constants don't change if we add/remove lines before the errc definition.
[Bug libstdc++/107008] Combine config/os/*/error_constants.h into one file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107008 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104883 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > A related topic is that we simply don't define the errc enumerators that > don't have a corresponding E macro, which is non-conforming. The C++ > standard says the enumerators should all be there. Oh that's PR 104883
[Bug libstdc++/104883] should define all std::errc enumerators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104883 --- Comment #1 from Jonathan Wakely --- >From PR 1007008 comment 2: -- >8 -- We could do something like this for each enumerator: #ifdef EFOO foo = EFOO, #else foo = _GLIBCXX_ERRC_ORIGIN + __LINE__, #endif Where _GLIBCXX_ERRC_ORIGIN is some value intended to be higher than the highest errno value on the OS. We only need fewer than 100 errc enumerators so INT_MAX/2 might be OK. We can use #line to set the __LINE__ to a fixed value in the file, so that the constants don't change if we add/remove lines before the errc definition. -- >8 -- We can use a default _GLIBCXX_ERRC_ORIGIN value, and allow it to be overridden in config/os/*/os_defines.h if the default doesn't work.
[Bug tree-optimization/99407] s243 benchmark of TSVC is vectorized by clang and not by gcc, missed DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99407 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4bdf739f835520ccbc433dc9eac461895741f317 commit r13-2769-g4bdf739f835520ccbc433dc9eac461895741f317 Author: Richard Biener Date: Thu Sep 22 09:40:40 2022 +0200 tree-optimization/99407 - DSE with data-ref analysis The following resolves the issue that DSE cannot handle references with variable offsets well when identifying possible uses of a store. Instead of just relying on ref_maybe_used_by_stmt_p we use data-ref analysis, making sure to perform that at most once per stmt. The new mode is only exercised by the DSE pass before loop optimization as specified by a new pass parameter and when expensive optimizations are enabled, so it's disabled below -O2. PR tree-optimization/99407 * tree-ssa-dse.cc (dse_stmt_to_dr_map): New global. (dse_classify_store): Use data-ref analysis to disambiguate more uses. (pass_dse::use_dr_analysis_p): New pass parameter. (pass_dse::set_pass_param): Implement. (pass_dse::execute): Allocate and deallocate dse_stmt_to_dr_map. * passes.def: Allow DR analysis for the DSE pass before loop. * gcc.dg/vect/tsvc/vect-tsvc-s243.c: Remove XFAIL.
[Bug tree-optimization/99407] s243 benchmark of TSVC is vectorized by clang and not by gcc, missed DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99407 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to work||13.0 Status|NEW |RESOLVED --- Comment #4 from Richard Biener --- Fixed for GCC 13.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 99407, which changed state. Bug 99407 Summary: s243 benchmark of TSVC is vectorized by clang and not by gcc, missed DSE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99407 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 Jiri Slaby changed: What|Removed |Added CC||jirislaby at gmail dot com --- Comment #11 from Jiri Slaby --- Looking at the kernel patch, it says: This is fixed now in gcc, but work around it on older compilers by using a wrapper. If so, how was this fixed an when (in what version)?
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 --- Comment #12 from Jiri Slaby --- (In reply to Jiri Slaby from comment #11) > Looking at the kernel patch, it says: > This is fixed now in gcc, but work around it on older compilers > by using a wrapper. > > If so, how was this fixed an when (in what version)? FWIW it builds with the patch reverted using gcc 12.
[Bug tree-optimization/106922] [12 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922 --- Comment #15 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:9baee6181b4e427e0b5ba417e51424c15858dce7 commit r13-2772-g9baee6181b4e427e0b5ba417e51424c15858dce7 Author: Richard Biener Date: Wed Sep 21 13:52:56 2022 +0200 tree-optimization/106922 - missed FRE/PRE The following enhances the store-with-same-value trick in vn_reference_lookup_3 by not only looking for a = val; *ptr = val; .. = a; but also *ptr = val; other = x; .. = a; where the earlier store is more than one hop away. It does this by queueing the actual value to compare until after the walk but as disadvantage only allows a single such skipped store from a constant value. Unfortunately we cannot handle defs from non-constants this way since we're prone to pick up values from the past loop iteration this way and we have no good way to identify values that are invariant in the currently iterated cycle. That's why we keep the single-hop lookup for those cases. gcc.dg/tree-ssa/pr87126.c would be a testcase that's un-XFAILed when we'd handle those as well. PR tree-optimization/106922 * tree-ssa-sccvn.cc (vn_walk_cb_data::same_val): New member. (vn_walk_cb_data::finish): Perform delayed verification of a skipped may-alias. (vn_reference_lookup_pieces): Likewise. (vn_reference_lookup): Likewise. (vn_reference_lookup_3): When skipping stores of the same value also handle constant stores that are more than a single VDEF away by delaying the verification. * gcc.dg/tree-ssa/ssa-fre-100.c: New testcase. * g++.dg/tree-ssa/pr106922.C: Adjust.
[Bug tree-optimization/106922] [12 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922 --- Comment #16 from Richard Biener --- This addressed the other missed optimization (which isn't a regression), it should make optimizing the m_initialized flag status more consistent.
[Bug tree-optimization/106950] Missed PRE full redundancy without post-loop use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106950 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Biener --- The very specifc case was addressed now, I don't think it's worth keeping this open since it also lacks a specific simpler testcase for the PRE issue that might still exist.
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 Richard Biener changed: What|Removed |Added Known to fail||12.2.0 Last reconfirmed|2021-03-30 00:00:00 |2022-9-22 --- Comment #13 from Richard Biener --- The testcase still does not work on master or with 12.2, thus reconfirmed.
[Bug c++/106997] Use coroutines on avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106997 --- Comment #2 from Wilhelm M --- I would consider this a missed optimization rather than a bug, because the standard says, that an implementation can avoid heap allocation if: - the lifetime of the coroutine is strictly within the lifetime of the caller - the size of coroutine state can be determined at compile time The case I tested falls within the above statement.
[Bug c/106830] [13 Regression] ICE: in tree_to_uhwi, at tree.cc:6392 (from check_for_xor_used_as_pow) since r13-2386-gbedfca647a9e9c1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106830 --- Comment #6 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:86254629b636db579616befde49022f098af8148 commit r13-2773-g86254629b636db579616befde49022f098af8148 Author: David Malcolm Date: Thu Sep 22 08:35:26 2022 -0400 c: fix uninitialized c_expr::m_decimal [PR106830] I added c_expr::m_decimal in r13-2386-gbedfca647a9e9c1a as part of the implementation of -Wxor-used-as-pow, but I missed various places where the field needed to be initialized. Fixed thusly. gcc/c-family/ChangeLog: PR c/106830 * c-warn.cc (check_for_xor_used_as_pow): Don't try checking values that don't fit in uhwi. gcc/c/ChangeLog: PR c/106830 * c-parser.cc (c_parser_initelt): Initialize m_decimal. (c_parser_cast_expression): Likewise. (c_parser_alignof_expression): Likewise. (c_parser_postfix_expression_after_paren_type): Likewise. (c_parser_postfix_expression_after_primary): Likewise. (c_parser_expression): Likewise. (c_parser_omp_variable_list): Likewise. (c_parser_transaction_expression): Likewise. * c-tree.h (c_expr::set_error): Likewise. * c-typeck.cc (c_expr_sizeof_expr): Likewise. (parser_build_unary_op): Likewise. (parser_build_binary_op): Likewise. (digest_init): Likewise. (pop_init_level): Likewise. * gimple-parser.cc (c_parser_gimple_call_internal): Likewise. gcc/testsuite/ChangeLog: PR c/106830 * gcc.dg/Wxor-used-as-pow-pr106830.c: New test. Signed-off-by: David Malcolm
[Bug c/106830] [13 Regression] ICE: in tree_to_uhwi, at tree.cc:6392 (from check_for_xor_used_as_pow) since r13-2386-gbedfca647a9e9c1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106830 David Malcolm changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from David Malcolm --- (In reply to CVS Commits from comment #6) > The master branch has been updated by David Malcolm : > > https://gcc.gnu.org/g:86254629b636db579616befde49022f098af8148 > > commit r13-2773-g86254629b636db579616befde49022f098af8148 Should be fixed by this commit; I've verified the original reproducer using valgrind. Sorry again about the breakage.
[Bug c++/106826] [13 Regression] [modules] Variable template of type trait via importable header gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106826 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:32d8123cd6ce87acb557aec230e8359051316f9f commit r13-2775-g32d8123cd6ce87acb557aec230e8359051316f9f Author: Patrick Palka Date: Thu Sep 22 08:46:23 2022 -0400 c++ modules: partial variable template specializations [PR106826] With partial variable template specializations, it looks like we stream the VAR_DECL (i.e. the DECL_TEMPLATE_RESULT of the corresponding TEMPLATE_DECL) since process_partial_specialization adds it to the specializations table, but we end up never streaming the corresponding TEMPLATE_DECL itself that's reachable only from the primary template's DECL_TEMPLATE_SPECIALIZATIONS list, which leads to this list being incomplete on stream-in. The modules machinery already has special logic for streaming partial specializations of class templates; this patch attempts to generalize it to handle those of variable templates as well. PR c++/106826 gcc/cp/ChangeLog: * module.cc (trees_out::decl_value): Use get_template_info in the MK_partial case to handle both VAR_DECL and TYPE_DECL. (trees_out::key_mergeable): Likewise. (trees_in::key_mergeable): Likewise. (has_definition): Consider DECL_INITIAL of a partial variable template specialization. (depset::hash::make_dependency): Handle partial variable template specializations too. gcc/testsuite/ChangeLog: * g++.dg/modules/partial-2_a.C: New test. * g++.dg/modules/partial-2_b.C: New test.
[Bug c/107002] [13 Regression] ICE in column_range, at diagnostic-show-locus.cc:2236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107002
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2022-09-22
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from David Malcolm ---
Probably introduced by r13-2386-gbedfca647a9e9c1a, which added
-Wxor-used-as-pow.
Failing assertion in column_range's ctor:
2233 column_range (int start_, int finish_) : start (start_), finish
(finish_)
2234 {
2235/* We must have either a range, or an insertion. */
2236gcc_assert (start <= finish || finish == start - 1);
2237 }
where:
(gdb) p start_
$1 = 5
(gdb) p finish_
$2 = 0
[Bug driver/106897] driver: support -gz=zstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106897 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #6 from Martin Liška --- Patch candidate: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602005.html
[Bug c++/106826] [13 Regression] [modules] Variable template of type trait via importable header gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106826 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Patrick Palka --- Fixed.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 106826, which changed state. Bug 106826 Summary: [13 Regression] [modules] Variable template of type trait via importable header gives wrong result https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106826 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/106826] [13 Regression] [modules] Variable template of type trait via importable header gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106826 --- Comment #6 from Patrick Palka --- *** Bug 100687 has been marked as a duplicate of this bug. ***
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 100687, which changed state. Bug 100687 Summary: [modules, concepts] imported concept gives different result https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100687 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/100687] [modules, concepts] imported concept gives different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100687 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Patrick Palka --- Should be fixed for GCC 13 by the fix for PR106826. *** This bug has been marked as a duplicate of bug 106826 ***
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 100687, which changed state. Bug 100687 Summary: [modules, concepts] imported concept gives different result https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100687 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/86465] [10/11/12/13 Regression] C++17 triggers: ‘’ may be used uninitialized in this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #21 from Richard Biener --- The original, the heavy simplified and Jonathans example no longer reproduce diagnostics for me on any active branch. The latest reported issue still is diagnosed with -fsanitize=address but that's a different issue. So let's close this.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 86465, which changed state. Bug 86465 Summary: [10/11/12/13 Regression] C++17 triggers: ‘’ may be used uninitialized in this function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/95825] [10/11/12/13 Regression] boost::optional -Wuninitialized with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95825 Richard Biener changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression] |boost::optional |boost::optional |-Wuninitialized |-Wuninitialized with ||-fsanitize=address Last reconfirmed|2020-08-04 00:00:00 |2022-9-22 --- Comment #6 from Richard Biener --- requires -fsanitize=address
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 102801, which changed state. Bug 102801 Summary: Incorrect -Wmaybe-uninitialized warning/interaction for a std::optional only when a nested struct is also present. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102801 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/102801] Incorrect -Wmaybe-uninitialized warning/interaction for a std::optional only when a nested struct is also present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102801 Richard Biener changed: What|Removed |Added Known to work||12.2.1, 13.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- The testcase no longer warns after GCC 12.2 or on GCC 13 trunk for me. I can re-confirm diagnostics with GCC 10 and GCC 11. I'm going to add the testcase and close this bug.
[Bug tree-optimization/102801] Incorrect -Wmaybe-uninitialized warning/interaction for a std::optional only when a nested struct is also present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102801 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:44dba051d72587828882cbb31118934a4fb06c1a commit r13-2776-g44dba051d72587828882cbb31118934a4fb06c1a Author: Richard Biener Date: Thu Sep 22 15:18:47 2022 +0200 tree-optimization/102801 - testcase for uninit diagnostic The following testcase is fixed in GCC 12+ PR tree-optimization/102801 gcc/testsuite/ * g++.dg/warn/Wuninitialized-33.C: New testcase.
[Bug tree-optimization/105749] Bogus maybe-unitialized when using std::optional, regex and sstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105749 Richard Biener changed: What|Removed |Added Known to fail||12.2.1, 13.0 Last reconfirmed||2022-09-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- Confirmed on the GCC 12 branch but on master the diagnostic only shows with -O1 now ...
[Bug c++/106826] [13 Regression] [modules] Variable template of type trait via importable header gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106826 --- Comment #7 from Johel Ernesto Guerrero Peña --- Thank you very much! This was a real blocker.
[Bug tree-optimization/107006] Missing optimization: common idiom for external data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006 --- Comment #11 from H. Peter Anvin --- If you look at the output, you see that the loops are already fully unrolled (at considerable code size cost.) Unfortunately, since the issue at hand is dealing with code written to be portable, adding gcc-specific hacks are not really a reasonable option.
[Bug tree-optimization/106989] GCC fail to vectorize and clang succeed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106989 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #6 from Andrew Pinski --- Exact dup of bug 99407. *** This bug has been marked as a duplicate of bug 99407 ***
[Bug tree-optimization/99407] s243 benchmark of TSVC is vectorized by clang and not by gcc, missed DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99407 Andrew Pinski changed: What|Removed |Added CC||juzhe.zhong at rivai dot ai --- Comment #5 from Andrew Pinski --- *** Bug 106989 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 106989, which changed state. Bug 106989 Summary: GCC fail to vectorize and clang succeed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106989 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c/106988] subscripting a string literal is not an integer constant expression but __builtin_strlen is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106988
Martin Sebor changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED|UNCONFIRMED
Keywords|diagnostic |rejects-valid
--- Comment #2 from Martin Sebor ---
After experimenting with this some more I think the decision to reject this and
the other similar requests should be reconsidered. GCC accepts many equivalent
nonconstant expressions in contexts where they are required (see below).
Rejecting the simplest of them seems arbitrary and is (as is evident from the
duplicate requests) unhelpful to C programmers and surprising those used to the
C++ behavior.
$ cat a.c && gcc -S -Wall -Wpedantic a.c
#include
_Static_assert (memcmp ("", "", 1) == 0, ""); // okay in C mode only
_Static_assert (memchr ("", 0, 1) != 0, ""); // okay in C mode only
_Static_assert (strlen ("") == 0, ""); // okay in C and C++
_Static_assert (strcmp ("", "") == 0, ""); // okay in C and C++
_Static_assert ("" == "", ""); // okay in C and C++
_Static_assert (*"" == 0, ""); // error in C only
a.c:3:36: warning: expression in static assertion is not an integer constant
expression [-Wpedantic]
3 | _Static_assert (memcmp ("", "", 1) == 0, ""); // okay in C mode only
| ~~~^~~~
a.c:4:35: warning: expression in static assertion is not an integer constant
expression [-Wpedantic]
4 | _Static_assert (memchr ("", 0, 1) != 0, ""); // okay in C mode only
| ~~^~~~
a.c:5:29: warning: expression in static assertion is not an integer constant
expression [-Wpedantic]
5 | _Static_assert (strlen ("") == 0, ""); // okay in C and C++
| ^~~~
a.c:6:33: warning: expression in static assertion is not an integer constant
expression [-Wpedantic]
6 | _Static_assert (strcmp ("", "") == 0, ""); // okay in C and C++
| ^~~~
a.c:7:20: warning: comparison with string literal results in unspecified
behavior [-Waddress]
7 | _Static_assert ("" == "", ""); // okay in C and C++
|^~
a.c:7:20: warning: expression in static assertion is not an integer constant
expression [-Wpedantic]
7 | _Static_assert ("" == "", ""); // okay in C and C++
| ~~~^
a.c:9:21: error: expression in static assertion is not constant
9 | _Static_assert (*"" == 0, ""); // error in C only
| ^~~~
[Bug libgcc/102017] libgcc ieee754-df.S for arm does not support exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102017 Torbjörn SVENSSON changed: What|Removed |Added CC||torbjorn.svensson at foss dot st.c ||om --- Comment #4 from Torbjörn SVENSSON --- I made an attempt to handle this for Arm as the number of failed tests related to this is growing with each new GCC version... Please review this patch https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602025.html and give me your feedback. Is this the right way to go? Is there a better way to go in order to avoid filling the log with fails that is not going to be addressed?
[Bug sanitizer/106998] [10/11/12/13 Regression] libsanitizer PATH_MAX not defined for linux new targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106998 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5 Summary|libsanitizer PATH_MAX not |[10/11/12/13 Regression] |defined for linux new |libsanitizer PATH_MAX not |targets |defined for linux new ||targets --- Comment #1 from Andrew Pinski --- This should be reported upstream but this is a regression due to a pull from upstream (r9-3752-geac975312214dc )
[Bug fortran/82868] ICE in generate_coarray_sym_init, at fortran/trans-decl.c:5203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82868 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:bc71318a91286b5f00e88f07aab818ac82510692 commit r13-2781-gbc71318a91286b5f00e88f07aab818ac82510692 Author: Harald Anlauf Date: Wed Sep 21 19:55:30 2022 +0200 Fortran: fix ICE in generate_coarray_sym_init [PR82868] gcc/fortran/ChangeLog: PR fortran/82868 * trans-decl.cc (generate_coarray_sym_init): Skip symbol if attr.associate_var. gcc/testsuite/ChangeLog: PR fortran/82868 * gfortran.dg/associate_26a.f90: New test.
[Bug fortran/100103] Automatic reallocation fails inside select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100103 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:12b537b9b7fd50f4b2fbfcb7ccf45f8d66085577 commit r13-2782-g12b537b9b7fd50f4b2fbfcb7ccf45f8d66085577 Author: José Rui Faustino de Sousa Date: Wed Sep 21 22:55:02 2022 +0200 Fortran: Fix automatic reallocation inside select rank [PR100103] gcc/fortran/ChangeLog: PR fortran/100103 * trans-array.cc (gfc_is_reallocatable_lhs): Add select rank temporary associate names as possible targets of automatic reallocation. gcc/testsuite/ChangeLog: PR fortran/100103 * gfortran.dg/PR100103.f90: New test.
[Bug fortran/106857] [10/11/12/13 Regression] ICE in gfc_simplify_pack, at fortran/simplify.cc:6438 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106857 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f954e0531beb8cbb128cc4ab70d65a92c5ac9a7d commit r11-10268-gf954e0531beb8cbb128cc4ab70d65a92c5ac9a7d Author: Harald Anlauf Date: Thu Sep 15 22:39:24 2022 +0200 Fortran: catch NULL pointer dereferences while simplifying PACK [PR106857] gcc/fortran/ChangeLog: PR fortran/106857 * simplify.c (gfc_simplify_pack): Check for NULL pointer dereferences while walking through constructors (error recovery). gcc/testsuite/ChangeLog: PR fortran/106857 * gfortran.dg/pr106857.f90: New test. (cherry picked from commit 2b75d5f533b9d6b39f4055949aff64ed0d22dd24)
[Bug fortran/106857] [10/11/12/13 Regression] ICE in gfc_simplify_pack, at fortran/simplify.cc:6438 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106857 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:cf172d0cdf355042223a3b1ebc04b472386a954e commit r10-10998-gcf172d0cdf355042223a3b1ebc04b472386a954e Author: Harald Anlauf Date: Thu Sep 15 22:39:24 2022 +0200 Fortran: catch NULL pointer dereferences while simplifying PACK [PR106857] gcc/fortran/ChangeLog: PR fortran/106857 * simplify.c (gfc_simplify_pack): Check for NULL pointer dereferences while walking through constructors (error recovery). gcc/testsuite/ChangeLog: PR fortran/106857 * gfortran.dg/pr106857.f90: New test. (cherry picked from commit 2b75d5f533b9d6b39f4055949aff64ed0d22dd24)
[Bug fortran/106857] [10/11/12/13 Regression] ICE in gfc_simplify_pack, at fortran/simplify.cc:6438 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106857 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/106986] [10/11/12/13 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.cc:5675
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106986 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:84a34d76a76f27feabd4523e388068c90c2bb2e4 commit r12-8782-g84a34d76a76f27feabd4523e388068c90c2bb2e4 Author: Harald Anlauf Date: Tue Sep 20 22:41:48 2022 +0200 Fortran: error recovery on invalid ARRAY argument to FINDLOC [PR106986] gcc/fortran/ChangeLog: PR fortran/106986 * simplify.cc (gfc_simplify_findloc): Do not try to simplify intrinsic FINDLOC when the ARRAY argument has a NULL shape. gcc/testsuite/ChangeLog: PR fortran/106986 * gfortran.dg/pr106986.f90: New test. (cherry picked from commit 5976fbf9d5dd9542fcb82eebb2185886fd52d000)
[Bug tree-optimization/107009] New: massive unnecessary code blowup in vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
Bug ID: 107009
Summary: massive unnecessary code blowup in vectorizer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Given an annotated saxpy function:
#include
void saxpy(size_t n, float* __restrict res, float a, const float* __restrict x,
const float* __restrict y)
{
if (n == 0 || n % 8 != 0)
__builtin_unreachable();
res = (float*)__builtin_assume_aligned(res, 32);
x = (const float*) __builtin_assume_aligned(x, 32);
y = (const float*) __builtin_assume_aligned(y, 32);
for (size_t i = 0; i < n; ++i)
res[i] = a * x[i] + y[i];
}
Compiling this with the gcc 12.2.1 version from Fedora 36 leads to the
expected, guided result (although the shrq isn't necessary…) with -O3:
_Z5saxpymPffPKfS1_:
.cfi_startproc
shrq$3, %rdi
vbroadcastss%xmm0, %ymm0
xorl%eax, %eax
salq$5, %rdi
.p2align 4
.p2align 3
.L2:
vmovaps (%rdx,%rax), %ymm1
vfmadd213ps (%rcx,%rax), %ymm0, %ymm1
vmovaps %ymm1, (%rsi,%rax)
addq$32, %rax
cmpq%rdi, %rax
jne .L2
vzeroupper
ret
The the current trunk gcc the result is massively bigger and given the guidance
in the sources none of the extra code is necessary.
_Z5saxpymPffPKfS1_:
.LFB22:
.cfi_startproc
movq%rdi, %r8
movq%rdx, %rdi
movq%rcx, %rdx
leaq-1(%r8), %rax
cmpq$6, %rax
jbe .L7
movq%r8, %rcx
vbroadcastss%xmm0, %ymm2
xorl%eax, %eax
shrq$3, %rcx
salq$5, %rcx
.p2align 4
.p2align 3
.L3:
vmovaps (%rdi,%rax), %ymm1
vfmadd213ps (%rdx,%rax), %ymm2, %ymm1
vmovaps %ymm1, (%rsi,%rax)
addq$32, %rax
cmpq%rcx, %rax
jne .L3
movq%r8, %rax
andq$-8, %rax
testb $7, %r8b
je .L18
vzeroupper
.L2:
movq%r8, %rcx
subq%rax, %rcx
leaq-1(%rcx), %r9
cmpq$2, %r9
jbe .L5
vmovaps (%rdx,%rax,4), %xmm3
vshufps $0, %xmm0, %xmm0, %xmm1
movq%rcx, %r9
vfmadd132ps (%rdi,%rax,4), %xmm3, %xmm1
andq$-4, %r9
vmovaps %xmm1, (%rsi,%rax,4)
addq%r9, %rax
andl$3, %ecx
je .L16
.L5:
vmovss (%rdi,%rax,4), %xmm1
leaq0(,%rax,4), %rcx
leaq1(%rax), %r9
vfmadd213ss (%rdx,%rax,4), %xmm0, %xmm1
vmovss %xmm1, (%rsi,%rcx)
cmpq%r8, %r9
jnb .L16
vmovss 4(%rdi,%rcx), %xmm1
addq$2, %rax
vfmadd213ss 4(%rdx,%rcx), %xmm0, %xmm1
vmovss %xmm1, 4(%rsi,%rcx)
cmpq%r8, %rax
jnb .L16
vmovss 8(%rdx,%rcx), %xmm4
vfmadd132ss 8(%rdi,%rcx), %xmm4, %xmm0
vmovss %xmm0, 8(%rsi,%rcx)
.L16:
ret
.p2align 4
.p2align 3
.L18:
vzeroupper
ret
.p2align 4
.p2align 3
.L7:
xorl%eax, %eax
jmp .L2
[Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009 Marek Polacek changed: What|Removed |Added Target Milestone|--- |13.0 Ever confirmed|0 |1 Summary|massive unnecessary code|[13 Regression] massive |blowup in vectorizer|unnecessary code blowup in ||vectorizer CC||aldyh at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Last reconfirmed||2022-09-22 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Looks like it was caused by r13-1268-g8c99e307b20c50: commit 8c99e307b20c502e55c425897fb3884ba8f05882 Author: Aldy Hernandez Date: Sat Jun 25 18:58:02 2022 -0400 Convert DOM to use Ranger rather than EVRP
[Bug c/107001] ICE in expand_gimple_stmt_1, at cfgexpand.cc:4017 since r9-3941-g28567c40e2c7c88e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107001 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-22 Ever confirmed|0 |1 Summary|ICE in |ICE in |expand_gimple_stmt_1, at|expand_gimple_stmt_1, at |cfgexpand.cc:4017 |cfgexpand.cc:4017 since ||r9-3941-g28567c40e2c7c88e --- Comment #1 from Martin Liška --- Started with r9-3941-g28567c40e2c7c88e, it was rejected before the revision.
[Bug c/107010] New: iterate section("mysection") struct mystruct fails if first node is const and compiling with O2 or greater
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107010
Bug ID: 107010
Summary: iterate section("mysection") struct mystruct fails if
first node is const and compiling with O2 or greater
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stian.skjelstad at gmail dot com
Target Milestone: ---
Created attachment 53612
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53612&action=edit
example setup compiled with both working and non-working flags
I have a use-case where plugins can be be compiled built in, and they are
detected by having some meta-data added to a section, and in runtime they can
be iterated.
#define SECTION __attribute__ ((section ("plugin_list")))
#define USED__attribute__ ((used))
Core code:
SECTION const struct plugindata first = {"dummy", 0, 0};
Each plugin (many copies):
SECTION USED static const struct plugindata = {"pluginname", foo, bar};
Last file linked contains a terminator
SECTION USED static const struct plugindata end = {0, 0, 0};
During linking they will gathered and can iterated using code like this:
void show_plugin_names(void)
{
const struct plugindata *iterator = &first;
while (iterator->name)
{
fprintf (stderr, "name=%s\n", iterator->name);
iterator++;
}
}
This works as long as you do not combine "first" being const and using gcc -O2
Tested with:
gcc-9 (Ubuntu 9.4.0-5ubuntu1) 9.4.0
gcc-10 (Ubuntu 10.3.0-15ubuntu1) 10.3.0
gcc-11 (Ubuntu 11.2.0-19ubuntu1) 11.2.0
gcc-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0
(using clang works)
I have also tested -fno-strict-aliasing -fwrapv and it didn't change the
behaviour.
I do accept that the use-case is probably a bit unorthodox and that it might be
dismissed as compiler-abuse.
[Bug c/107010] iterate section("mysection") struct mystruct fails if first node is const and compiling with O2 or greater
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107010
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=77964
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
That is because GCC knows that first+1 does not point to a valid pointer
really.
You need to hide the assignment of iterator from GCC.
This will fix the issue:
const struct linkinfostruct *iterator = &first;
asm("":"+r"(iterator));
while (iterator->name)
{
fprintf (stderr, "name=%s\n", iterator->name);
iterator++;
fprintf (stderr, "next iteration should be (iterator=%p,
&iterator->name=%p name=%p \"%s\"\n", iterator, &iterator->name,
iterator->name, iterator->name);
}
See PR 77964 and PR 106939 also.
[Bug c++/107003] ICE in mangle_decl, at cp/mangle.cc:4112 since r6-1066-g233ce289250944dd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107003
Martin Liška changed:
What|Removed |Added
Summary|ICE in mangle_decl, at |ICE in mangle_decl, at
|cp/mangle.cc:4112 |cp/mangle.cc:4112 since
||r6-1066-g233ce289250944dd
CC||hubicka at gcc dot gnu.org,
||marxin at gcc dot gnu.org
--- Comment #2 from Martin Liška ---
Reduced test-case:
$ cat pr107003.ii
template < typename _Default, template < typename > class >
using __detected_or_t = _Default;
template < typename, typename > struct __replace_first_arg;
template < template < typename... > class _Template, typename _Up, typename
_Tp,
typename... _Types >
struct __replace_first_arg< _Template< _Tp, _Types... >, _Up > {
using type = _Template< _Up >;
};
template < typename _Tp > using __pointer = typename _Tp::pointer;
template < typename _Tp > struct __rebind : __replace_first_arg< _Tp, int > {};
template < typename _Alloc, typename >
using __alloc_rebind = typename __rebind< _Alloc >::type;
template < typename _Alloc > struct allocator_traits {
using pointer = __detected_or_t< typename _Alloc::value_type *, __pointer >;
template < typename _Tp > using rebind_alloc = __alloc_rebind< _Alloc, _Tp >;
static void deallocate(_Alloc __a, pointer __p, int __n) {
__a.deallocate(__p, __n);
}
};
template < typename _Alloc >
struct __alloc_traits : allocator_traits< _Alloc > {
template < typename > struct rebind {
typedef typename allocator_traits< _Alloc >::template rebind_alloc< int >
other;
};
};
template < typename _Alloc > struct _List_base {
typedef __alloc_traits< _Alloc > _Tp_alloc_traits;
typedef
typename _Tp_alloc_traits::template rebind< int >::other
_Node_alloc_type;
typedef __alloc_traits< _Node_alloc_type > _Node_alloc_traits;
struct : _Node_alloc_type {
} _M_impl;
typename _Node_alloc_traits::pointer _M_put_node___p;
_List_base() { _Node_alloc_traits::deallocate(_M_impl, _M_put_node___p, 1); }
};
namespace experimental {
inline namespace fundamentals_v2 {
void *deallocate___p;
long deallocate___bytes;
long deallocate___alignment;
struct memory_resource {
void deallocate() {
do_deallocate(deallocate___p, deallocate___bytes, deallocate___alignment);
}
virtual void do_deallocate(void *, unsigned long, unsigned long);
};
template < class > struct polymorphic_allocator {
using value_type = int;
void deallocate(int *, long) { _M_resource.deallocate(); }
memory_resource _M_resource;
};
inline void null_memory_resource() {
struct final : memory_resource {
void do_deallocate(void *, unsigned long, unsigned long) {}
};
}
template < typename _Tp >
using list = _List_base< polymorphic_allocator< _Tp > >;
} list< int > a;
}
started failing since r6-1066-g233ce289250944dd.
[Bug fortran/106999] [11/12/13 Regression] ICE tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.cc:233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106999 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Also GCC 4.8 ICEs.
[Bug c/107002] [13 Regression] ICE in column_range, at diagnostic-show-locus.cc:2236 since r13-2386-gbedfca647a9e9c1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107002 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Summary|[13 Regression] ICE in |[13 Regression] ICE in |column_range, at|column_range, at |diagnostic-show-locus.cc:22 |diagnostic-show-locus.cc:22 |36 |36 since ||r13-2386-gbedfca647a9e9c1a --- Comment #2 from Martin Liška --- (In reply to David Malcolm from comment #1) > Probably introduced by r13-2386-gbedfca647a9e9c1a, which added Yes.
[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106939 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- In C99, it is in 6.5.8/5 (Relational operators).
[Bug target/106919] [13 Regression] RTL check: expected code 'set' or 'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919 --- Comment #5 from Martin Liška --- Confirmed, bisecting right now.
[Bug c/107010] iterate section("mysection") struct mystruct fails if first node is const and compiling with O2 or greater
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107010 --- Comment #2 from Stian Skjelstad --- Thank you for an amazing fast usefull reply.
[Bug tree-optimization/107011] New: instruction with undefined behavior not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107011
Bug ID: 107011
Summary: instruction with undefined behavior not optimized away
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
#include
int main() {
return INT_MIN / -1;
}
$ gcc -O3
main:
mov eax, -2147483648
ret
$ clang -O3
main: # @main
ret
https://godbolt.org/z/393EMqs1E
PS: I reported this bug yesterday as well but for some reason it does not
appear in bugzilla so I'm creating another one.
[Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009 --- Comment #2 from Aldy Hernandez --- (In reply to Marek Polacek from comment #1) > Looks like it was caused by r13-1268-g8c99e307b20c50: > > commit 8c99e307b20c502e55c425897fb3884ba8f05882 > Author: Aldy Hernandez > Date: Sat Jun 25 18:58:02 2022 -0400 > > Convert DOM to use Ranger rather than EVRP Note that this patch is usually a red herring. It makes DOM smarter by improving its copy propagation and threading capabilities. And when DOM is done, it will export whatever global ranges it discovered to other passes. Any number of these things could cause the vectorizer to make different decisions. I'll take a look tomorrow though.
[Bug tree-optimization/107011] instruction with undefined behavior not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107011 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- (In reply to AK from comment #0) > PS: I reported this bug yesterday as well but for some reason it does not > appear in bugzilla so I'm creating another one. That is because it was closed as won't fix. Dup of bug 107005. *** This bug has been marked as a duplicate of bug 107005 ***
[Bug tree-optimization/107005] gcc not exploiting undefined behavior to optimize away the result of division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107005 --- Comment #4 from Andrew Pinski --- *** Bug 107011 has been marked as a duplicate of this bug. ***
[Bug target/106919] [13 Regression] RTL check: expected code 'set' or 'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672on s390x-linux-gnu since r13-2251-g1930c5d05ceff2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919 Martin Liška changed: What|Removed |Added Summary|[13 Regression] RTL check: |[13 Regression] RTL check: |expected code 'set' or |expected code 'set' or |'clobber', have |'clobber', have |'if_then_else' in |'if_then_else' in |s390_rtx_costs, at |s390_rtx_costs, at |config/s390/s390.cc:3672on |config/s390/s390.cc:3672on |s390x-linux-gnu |s390x-linux-gnu since ||r13-2251-g1930c5d05ceff2 CC||rdapp at gcc dot gnu.org --- Comment #6 from Martin Liška --- Started with r13-2251-g1930c5d05ceff2.
[Bug target/106919] [13 Regression] RTL check: expected code 'set' or 'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672on s390x-linux-gnu since r13-2251-g1930c5d05ceff2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919
--- Comment #7 from Martin Liška ---
Fixed with:
diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 076c97a8b22..869847ab3d7 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -3669,7 +3669,7 @@ s390_rtx_costs (rtx x, machine_mode mode, int outer_code,
slightly more expensive than a normal load. */
*total = COSTS_N_INSNS (1) + 2;
- rtx dst = SET_DEST (src);
+ rtx dst = dest;
rtx then = XEXP (src, 1);
rtx els = XEXP (src, 2);
But I think the declaration of 'dest' should be removed:
diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 076c97a8b22..fa571c0190a 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -3648,7 +3648,7 @@ s390_rtx_costs (rtx x, machine_mode mode, int outer_code,
*total = 0;
return true;
case SET: {
- rtx dest = SET_DEST (x);
+ rtx dst = SET_DEST (x);
rtx src = SET_SRC (x);
switch (GET_CODE (src))
@@ -3669,7 +3669,6 @@ s390_rtx_costs (rtx x, machine_mode mode, int outer_code,
slightly more expensive than a normal load. */
*total = COSTS_N_INSNS (1) + 2;
- rtx dst = SET_DEST (src);
rtx then = XEXP (src, 1);
rtx els = XEXP (src, 2);
@@ -3696,25 +3695,25 @@ s390_rtx_costs (rtx x, machine_mode mode, int
outer_code,
break;
}
- switch (GET_CODE (dest))
+ switch (GET_CODE (dst))
{
case SUBREG:
- if (!REG_P (SUBREG_REG (dest)))
+ if (!REG_P (SUBREG_REG (dst)))
*total += rtx_cost (SUBREG_REG (src), VOIDmode, SET, 0, speed);
/* fallthrough */
case REG:
/* If this is a VR -> VR copy, count the number of
registers. */
- if (VECTOR_MODE_P (GET_MODE (dest)) && REG_P (src))
+ if (VECTOR_MODE_P (GET_MODE (dst)) && REG_P (src))
{
- int nregs = s390_hard_regno_nregs (VR0_REGNUM, GET_MODE
(dest));
+ int nregs = s390_hard_regno_nregs (VR0_REGNUM, GET_MODE (dst));
*total = COSTS_N_INSNS (nregs);
}
/* Same for GPRs. */
else if (REG_P (src))
{
int nregs
- = s390_hard_regno_nregs (GPR0_REGNUM, GET_MODE (dest));
+ = s390_hard_regno_nregs (GPR0_REGNUM, GET_MODE (dst));
*total = COSTS_N_INSNS (nregs);
}
else
@@ -3722,7 +3721,7 @@ s390_rtx_costs (rtx x, machine_mode mode, int outer_code,
*total += rtx_cost (src, mode, SET, 1, speed);
return true;
case MEM: {
- rtx address = XEXP (dest, 0);
+ rtx address = XEXP (dst, 0);
rtx tmp;
long tmp2;
if (s390_loadrelative_operand_p (address, &tmp, &tmp2))
@Robin: What do you think?
[Bug libstdc++/104883] should define all std::errc enumerators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104883 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-09-22 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- Created attachment 53613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53613&action=edit Generate error_constants.h from Instead of having several very similar target-specific headers with slightly different sets of enumerators, generate the error_constants.h file as part of the build. This ensures that all enumerators are always defined, with the value from the corresponding errno macro if present, or a libstdc++-specific alternative value. The libstdc++-specific values will be values greater than the positive integer _GLIBCXX_ERRC_ORIGIN, which defaults to but can be set in os_defines.h if a more suitable value exists for the OS (e.g. ELAST could be used for BSD targets). The advantage of doing this is that we get a header that can be used freestanding, but with values that match the hosted errno.h (if one exists on the target).
[Bug debug/107012] New: [debug, dwarf-5] Missing line information for evaluating macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107012
Bug ID: 107012
Summary: [debug, dwarf-5] Missing line information for
evaluating macros
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: gandalf at winds dot org
Target Milestone: ---
Created attachment 53614
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53614&action=edit
objdump output for dwarf-4
GCC 12 now defaults to outputting debug information via dwarf-5. Compared to
dwarf-4 (which works), gdb's interpretation of dwarf-5 seems to show that we're
missing the correct line information, which causes gdb to not be able to
correctly find and evaluate a macro on the command line due to being in the
wrong context. It's not clear whether gcc is not correctly emitting all the
information, or if gdb is not correctly reading all the information.
Breaking at the "main" function and attempting to run "info macro X" produces
the error message, "The symbol `X' has no definition as a C/C++ preprocessor
macro at macro.c:-1".
The same behavior happens when breaking at any other point in a C program, and
not just at "main".
In both examples below, the breakpoint output shows we're at line 5 in macro.c:
$ cat macro.c
#define TEST_MACRO 42
int main()
{
return 0;
}
### DWARF-4 Example ###
$ gcc -O3 -ggdb3 -gdwarf-4 macro.c -o macro
$ gdb macro
GNU gdb (Gentoo 12.1 vanilla) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-12.2.0/work/gcc-12.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/12.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/12.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/12.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/12.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/g++-v12
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/12.
[Bug debug/107012] [debug, dwarf-5] Missing line information for evaluating macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107012 --- Comment #1 from gandalf at winds dot org --- Created attachment 53615 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53615&action=edit objdump output for dwarf-5
[Bug tree-optimization/107011] instruction with undefined behavior not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107011 --- Comment #2 from AK --- ah ok. sorry for the noise.
[Bug c++/106983] [12/13 Regression] ICE tree check: expected class 'type', have 'exceptional' (error_mark) in type_build_dtor_call, at cp/class.cc:5794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106983 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:8b449dcd84334068c769a2f427812dadb95e61de commit r13-2803-g8b449dcd84334068c769a2f427812dadb95e61de Author: Marek Polacek Date: Tue Sep 20 14:54:57 2022 -0400 c++: ICE-on-invalid with designated initializer [PR106983] We ICE in the code added in r12-7117: type_build_dtor_call gets the error_mark_node because the type of 'prev' wasn't declared. PR c++/106983 gcc/cp/ChangeLog: * typeck2.cc (split_nonconstant_init_1): Check TYPE_P. gcc/testsuite/ChangeLog: * g++.dg/other/error36.C: New test.
[Bug c++/106983] [12/13 Regression] ICE tree check: expected class 'type', have 'exceptional' (error_mark) in type_build_dtor_call, at cp/class.cc:5794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106983 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug rtl-optimization/107013] New: Add fmin/fmax to RTL codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107013
Bug ID: 107013
Summary: Add fmin/fmax to RTL codes
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
Could we add fmin/fmax to RTL codes so that the C standard fmin/fmax can be
represented in RTL without UNSPECs? Currently we only have smin/smax that are
not valid for NaNs, or when the sign of zeros is relevant.
C standard for fmax
F.10.9.2 The fmax functions
1 If just one argument is a NaN, the fmax functions return the other argument
(if both arguments are NaNs, the functions return a NaN).
2 The returned value is exact and is independent of the current rounding
direction mode.
3 The body of the fmax function might be374)
{ return (isgreaterequal(x, y) ||
isnan(y)) ? x : y; }
Footnotes
374) Ideally, fmax would be sensitive to the sign of zero, for example
fmax(-0.0, +0.0) would return +0; however, implementation in software might be
impractical.
[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 --- Comment #8 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:a282f086ef26d90e9785e992cd09a0d118b24695 commit r13-2804-ga282f086ef26d90e9785e992cd09a0d118b24695 Author: Hu, Lin1 Date: Tue Sep 13 16:28:54 2022 +0800 i386: Optimize code generation of __mm256_zextsi128_si256(__mm_set1_epi8(-1)) gcc/ChangeLog: PR target/94962 * config/i386/constraints.md (BH): New define_constraint. * config/i386/i386.cc (standard_sse_constant_p): Add return 3/4 when operand matches new predicate. (standard_sse_constant_opcode): Add new alternative branch to return "vpcmpeqd". * config/i386/predicates.md (vector_all_ones_zero_extend_half_operand): New define_predicate. (vector_all_ones_zero_extend_quarter_operand): Ditto. * config/i386/sse.md: Add constraint to insn "mov_internal". gcc/testsuite/ChangeLog: PR target/94962 * gcc.target/i386/avx256-unaligned-load-1.c: Modify test. * gcc.target/i386/avx256-unaligned-store-1.c: Ditto. * gcc.target/i386/avx256-unaligned-store-2.c: Ditto. * gcc.target/i386/avx256-unaligned-store-3.c: Ditto. * gcc.target/i386/pr94962-1.c: New test. * gcc.target/i386/pr94962-2.c: Ditto. * gcc.target/i386/pr94962-3.c: Ditto. * gcc.target/i386/pr94962-4.c: Ditto.
[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 --- Comment #9 from Hongtao.liu --- Fixed in trunk.
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #14 from Jiri Slaby ---
(In reply to Richard Biener from comment #13)
> The testcase still does not work on master or with 12.2, thus reconfirmed.
Hmm:
(In reply to Martin Liška from comment #0)
> Noticed by Andi Kleen in kernel, reduced to:
>
> $ cat 1.i
> __attribute__((__always_inline__)) void *memcpy();
> void *foo = memcpy;
Provided I cannot reproduce on the current kernel, where exactly does this come
from?
I see:
arch/x86/include/asm/string_64.h:
#define __HAVE_ARCH_MEMCPY 1
extern void *memcpy(void *to, const void *from, size_t len);
extern void *__memcpy(void *to, const void *from, size_t len);
===
For KASAN also:
#if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__)
#undef memcpy
#define memcpy(dst, src, len) __memcpy(dst, src, len)
===
arch/x86/lib/memcpy_64.S:
SYM_FUNC_START(__memcpy)
...
SYM_FUNC_END(__memcpy)
...
SYM_FUNC_ALIAS_WEAK(memcpy, __memcpy)
===
$ nm ../lto/vmlinux|grep -wE '__memcpy|memcpy'
81dcf0b0 T __memcpy
81dcf0b0 W memcpy
===
arch/x86/lib/memcpy_32.c:
__used __visible void *memcpy(void *to, const void *from, size_t n)
{
return __memcpy(to, from, n);
}
[Bug tree-optimization/107006] Missing optimization: common idiom for external data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006 --- Comment #12 from Richard Biener --- (In reply to H. Peter Anvin from comment #11) > If you look at the output, you see that the loops are already fully unrolled > (at considerable code size cost.) The unrolling is done too late for the bswap detection pass to trigger. > Unfortunately, since the issue at hand is dealing with code written to be > portable, adding gcc-specific hacks are not really a reasonable option. Well, #pragma GCC unroll n is "portable" in that #pragma is an ISO C feature and pragmas in the 'GCC' domain are supposed to be ignored by other compilers, so not sure what you are wanting to say here. You can also manually unroll of course. Alternatively somebody can try to implement loop pattern matching for bswap/load. It's a reduction so blueprints might be available by the strlen pattern matching in loop_distribution::transform_reduction_loop.
[Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P1 CC||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- # RANGE [irange] size_t [1, +INF] size_t n_12(D) = n; the nonzero bits info on 'n' is gone. DOM2 used to produce that and CCP3 elides the __builtin_unreachable () but if DOM2 is disabled that doesn't produce the nonzero bits. DOM2 from trunk no longer sets nonzero bits. CCP doesn't do any conditional non-zero bits (or constant equivalence) propagation.
