[Bug tree-optimization/106900] Regression after memchr optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106900 --- Comment #2 from Andrew Pinski --- Obviously this only happens because you use --enable-werror-always
[Bug tree-optimization/106900] Regression after memchr optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106900 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Andrew Pinski --- Looks like gcc can't figure out that isize can't be 0 even if there was a check for integer_zerop (size) before hand. There must be a way to add an assert there to allow gcc to figure that out.
[Bug tree-optimization/106900] New: Regression after memchr optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106900
Bug ID: 106900
Summary: Regression after memchr optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jbg...@lug-owl.de
Target Milestone: ---
Hi!
The optimization prepared in PR103798 ("memchr with a (small) constant string
should be expanded inline", c6cf555a88f8ffb8ec85c2b94fe656ab217260ea) caused a
regression for avr-elf, pru-elf and rl78-elf:
.../gcc/configure --prefix=... --enable-werror-always --enable-languages=all
--disable-gcov --disable-shared --disable-threads --target=pru-elf
--without-headers
[...]
make V=1 all-gcc
[...]
/usr/lib/gcc-snapshot/bin/g++ -fno-PIE -c -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -W
cast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libcody -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc/gcc/../libbacktrace -o tree-ssa-forwprop.o -MT
tree-ssa-forwprop.o -MMD -MP -MF ./.deps/tree-ssa-forwprop.TPo
../../gcc/gcc/tree-ssa-forwprop.cc
../../gcc/gcc/tree-ssa-forwprop.cc: In function 'bool
simplify_builtin_call(gimple_stmt_iterator*, tree)':
../../gcc/gcc/tree-ssa-forwprop.cc:1258:42: error: array subscript 1 is outside
array bounds of 'tree_node* [1]' [-Werror=array-bounds]
1258 | op[i - 1] = fold_convert_loc (loc, boolean_type_node,
| ~^~~~
1259 | fold_build2_loc (loc,
| ~
1260 |
BIT_IOR_EXPR,
|
~
1261 |
boolean_type_node,
|
~~
1262 |op[i - 1],
|~~
1263 |op[i]));
|~~~
In file included from ../../gcc/gcc/system.h:707,
from ../../gcc/gcc/tree-ssa-forwprop.cc:21:
../../gcc/gcc/../include/libiberty.h:733:36: note: at offset 8 into object of
size [0, 8] allocated by '__builtin_alloca'
733 | # define alloca(x) __builtin_alloca(x)
|^~~
../../gcc/gcc/../include/libiberty.h:365:40: note: in expansion of macro
'alloca'
365 | #define XALLOCAVEC(T, N)((T *) alloca (sizeof (T) * (N)))
|^~
../../gcc/gcc/tree-ssa-forwprop.cc:1250:22: note: in expansion of macro
'XALLOCAVEC'
1250 | tree *op = XALLOCAVEC (tree, isize);
| ^~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:1146: tree-ssa-forwprop.o] Error 1
(Last confirmed at c2c3e4f6698925c8c969d8525677fbfe98f78909.)
[Bug other/106899] Snapshots do not contain pre-generated man pages & info pages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899 --- Comment #4 from Andrew Pinski --- So the issue is when we do a release, do a full build of GCC. Doing a snapshot does NOT do the full build because of resource constraints. We have at least any one time, 4 snapshots happening during the week. the machine which hosts gcc is doing the snapshots so taking resources away from other projects too. We could do this yes but I doubt we want to do for a few reasons. 1) No longer a true snapshot of the source. 2) resource constraints on building the snapshot 3) building the generated files while using snapshot/git is not a bad thing
[Bug libstdc++/106803] views::adjacent_transform should not return views::empty> when N == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106803
--- Comment #5 from 康桓瑋 ---
(In reply to Patrick Palka from comment #4)
> Fixed, thanks very much for the bug reports.
Hey Patrick, thanks for the prompt fix.
However, I think there may be some issues with this fix, consider:
struct F {
F() = default;
F(const F&) = delete;
void operator()() = delete;
};
auto r = std::views::zip_transform(F{});
There are two problems here, the first less important one is that F is not
callable, so views::empty<...> in the function body would be a hard error; the
second one is that when empty pack, [range.zip.transform.overview] explicitly
requires that F must be copy_constructible (this should be move_constructible
because of p2494, I have submitted LWG for this), so even if F provides
operator(), we still need to reject the above.
[Bug other/106899] Snapshots do not contain pre-generated man pages & info pages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899 --- Comment #3 from Sam James --- Yeah, I understand it's not an error per se, just wondering if it could be considered to add them. It looks like they're generated from the same script used for releases: maintainer-scripts/gcc_release (as it handles announcing them too, and diffs, etc). I didn't realise it didn't do a test build at all (figured if it did, could just shove in --enable-generated-files-in-srcdir). At least the machinery is largely there, but it'd involve actually doing at least a minimal build before generating the snapshots.
[Bug driver/106897] driver: support -gz=zstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106897 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Severity|normal |enhancement Last reconfirmed||2022-09-10 Ever confirmed|0 |1
[Bug other/106899] Snapshots do not contain pre-generated man pages & info pages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899 --- Comment #2 from Andrew Pinski --- "Public releases and weekly snapshots of the development sources are also available via HTTPS." "Necessary to build GCC documentation during development because the generated output files are not included in the repository. They are included in releases." >From https://gcc.gnu.org/install/prerequisites.html Also I suspect building the snapshot with the generated files will no longer be considered a snapshot but a snap release instead. Since it is not exactly what is in the git repo anymore.
[Bug other/106899] Snapshots do not contain pre-generated man pages & info pages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899 --- Comment #1 from Andrew Pinski --- Right this is done on purpose as snapshots are just snapshots of the sources directly from the git.
[Bug other/106899] New: Snapshots do not contain pre-generated man pages & info pages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899 Bug ID: 106899 Summary: Snapshots do not contain pre-generated man pages & info pages Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: sam at gentoo dot org Target Milestone: --- Would it be possible for the weekly snapshots to include pre-generated .info pages (and man pages)? Full releases do: ``` # find . | grep -i "\.info$" ./gcc-11.3.0/libquadmath/libquadmath.info ./gcc-11.3.0/libgomp/libgomp.info ./gcc-11.3.0/libitm/libitm.info ./gcc-11.3.0/gcc/fortran/gfortran.info ./gcc-11.3.0/gcc/doc/gccinstall.info ./gcc-11.3.0/gcc/doc/gccint.info ./gcc-11.3.0/gcc/doc/cpp.info ./gcc-11.3.0/gcc/doc/cppinternals.info ./gcc-11.3.0/gcc/doc/gcc.info ``` But snapshots don't: ``` /var/tmp/portage/sys-devel/gcc-11.3.1_p20220909/work # find . | grep -i "\.info$" /var/tmp/portage/sys-devel/gcc-11.3.1_p20220909/work # ```
[Bug c++/106898] New: ECF_NOTHROW for __cxa_deleted_virtual or not for __cxa_pure_virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106898 Bug ID: 106898 Summary: ECF_NOTHROW for __cxa_deleted_virtual or not for __cxa_pure_virtual Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: aoliva at gcc dot gnu.org Target Milestone: --- I see no reason for the difference WRT ECF_NOTHROW between __cxa_deleted_virtual and __cxa_pure_virtual library declarations pushed in decl.cc and class.cc, respectively. Their implementations behave essentially the same, I suppose both might be user-overridable (though I see no evidence that this is indeed the case), and neither promises not to throw in the C++ ABI document (but I realize throwing from either one could be problematic if the virtual method happens to be nothrow). Unless there's good reason to keep this flag difference, IMHO it would be desirable to resolve the inconsistency one way or another.
[Bug driver/106897] driver: support -gz=zstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106897 --- Comment #3 from Andrew Pinski --- The hardest part is the configure change I think gcc_GAS_CHECK_FEATURE([compressed debug sections],
[Bug driver/106897] driver: support -gz=zstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106897 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Hmm, does gcc already support translating -gz ? The answer to my own question is yes. Adding zstd should be a simple patch I suspect.
[Bug driver/106897] driver: support -gz=zstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106897 --- Comment #1 from Andrew Pinski --- Hmm, does gcc already support translating -gz ?
[Bug driver/106897] New: driver: support -gz=zstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106897 Bug ID: 106897 Summary: driver: support -gz=zstd Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: i at maskray dot me Target Milestone: --- Translate -gz=std to --compress-debug-sections=zstd for as and ld. This requires that binutils supports zstd, feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=29397
[Bug c++/100288] [11/12/13 Regression] g++-11 internal error and fails to precompile a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100288 Patrick Palka changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #12 from Patrick Palka --- *** Bug 106801 has been marked as a duplicate of this bug. ***
[Bug c++/106801] ICE: in get, at cp/constraint.cc:2621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106801 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- dup of PR100288 *** This bug has been marked as a duplicate of bug 100288 ***
[Bug analyzer/98247] Analyzer fails to detect certain out-of-bounds uses of flexible array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98247
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|RFE: detect Flexible Array |Analyzer fails to detect
|Member misuse in analyzer |certain out-of-bounds uses
||of flexible array members
Last reconfirmed||2022-09-09
Status|UNCONFIRMED |NEW
Version|11.0|13.0
--- Comment #5 from David Malcolm ---
The above patch adds test coverage for various uses of the flexible array
member idiom, inspired by your test case above (thanks!)
It adds one xfail; in test_symbolic_size_oob, where there's a false negative,
where it fails to complain about this code:
struct str *
test_symbolic_size_oob (size_t len)
{
/* Forgetting to add space for the trailing array. */
struct str *str = malloc(sizeof(str));
if (str) {
str->len = len;
memset(str->data, 'x', len); /* { dg-warning "heap-based buffer overflow"
"PR analyzer/98247" { xfail *-*-* } } */
// TODO(xfail): we don't yet complain about this case, which occurs when
len > 0
return str;
}
return NULL;
}
I'm going to repurpose this bug to track fixing that false negative; updating
subject accordingly.
[Bug analyzer/98247] RFE: detect Flexible Array Member misuse in analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98247 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:084dc9a0c6cec14596093ad077fc3e25c6b99bc3 commit r13-2571-g084dc9a0c6cec14596093ad077fc3e25c6b99bc3 Author: David Malcolm Date: Fri Sep 9 17:10:08 2022 -0400 analyzer: add test coverage for flexible array members [PR98247] gcc/testsuite/ChangeLog: PR analyzer/98247 * gcc.dg/analyzer/flexible-array-member-1.c: New test. Signed-off-by: David Malcolm
[Bug libstdc++/106803] views::adjacent_transform should not return views::empty> when N == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106803 Patrick Palka changed: What|Removed |Added Target Milestone|--- |13.0 Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Patrick Palka --- Fixed, thanks very much for the bug reports.
[Bug libstdc++/106798] adjacent_view::_Iterator(_Iterator) requires random_access_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106798 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |RESOLVED Target Milestone|--- |13.0 --- Comment #4 from Patrick Palka --- Fixed.
[Bug libstdc++/106766] zip_view::_Iterator/_Sentinel's operator- use make_unsigned_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106766 Patrick Palka changed: What|Removed |Added Target Milestone|--- |13.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Patrick Palka --- Fixed.
[Bug libstdc++/106803] views::adjacent_transform should not return views::empty> when N == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106803 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:8298427f6b546cabb853edd45c009cd1967b9d38 commit r13-2569-g8298427f6b546cabb853edd45c009cd1967b9d38 Author: Patrick Palka Date: Fri Sep 9 14:59:14 2022 -0400 libstdc++: Fix return type of empty zip_/adjacent_transform [PR106803] PR libstdc++/106803 libstdc++-v3/ChangeLog: * include/std/ranges (views::_ZipTransform::operator()): Correct return type in the empty case. (views::_AdjacentTransform::operator()): Likewise.
[Bug libstdc++/106798] adjacent_view::_Iterator(_Iterator) requires random_access_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106798 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:e469506b7fdd1bf2c958ca3140573a474fcba3b8 commit r13-2568-ge469506b7fdd1bf2c958ca3140573a474fcba3b8 Author: Patrick Palka Date: Fri Sep 9 14:56:37 2022 -0400 libstdc++: Fix typo in adjacent_view::_Iterator [PR106798] PR libstdc++/106798 libstdc++-v3/ChangeLog: * include/std/ranges (adjacent_view::_Iterator::_Iterator): Fix typo. * testsuite/std/ranges/adaptors/adjacent/1.cc (test04): New test.
[Bug libstdc++/106766] zip_view::_Iterator/_Sentinel's operator- use make_unsigned_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106766 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:718a6d475b3d17759618c68331c85f55c58ec9a3 commit r13-2567-g718a6d475b3d17759618c68331c85f55c58ec9a3 Author: Patrick Palka Date: Fri Sep 9 14:56:32 2022 -0400 libstdc++: Fix zip_view's operator- for integer-class difference type [PR106766] The difference type of an underlying iterator could be an integer-class type, which make_unsigned_t doesn't handle, so we need to use the more general __make_unsigned_like_t / __to_unsigned_like here instead. PR libstdc++/106766 libstdc++-v3/ChangeLog: * include/std/ranges (zip_view::_Iterator::operator-): Use __to_unsigned_like instead of make_unsigned_t. (zip_view::_Sentinel::operator-): Likewise. * testsuite/std/ranges/zip/1.cc (test04): New test.
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 Jakub Jelinek changed: What|Removed |Added Attachment #53555|0 |1 is obsolete|| --- Comment #9 from Jakub Jelinek --- Created attachment 53557 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53557&action=edit gcc13-pr106652-wip.patch Further updated patch which implements also the 4) diagnostics, both for binary operations and ?: and punts in c-common.c uses if common_type fails, plus an added x86 specific tests for further errors and a powerpc specific test to test for the long double (IBM extended) vs. _Float128 unordered conversion ranks. [over.ics.rank] changes are still not implemented and I'm lost there.
[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106894 Jakub Jelinek changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #6 from Jakub Jelinek --- .
[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106894
--- Comment #5 from Jakub Jelinek ---
Ah, sorry about icv-6.c, I did debug just one of the testcases and after fixing
it tested all the mentioned tests and all passed, so thought it is fixed.
I can now reproduce it though.
The thing is,
make check
or
make check RUNTESTFLAGS="c.exp='icv-6.c' c++.exp='icv-6.c'"
in libgomp obj dir work fine, but
make -j32 -k check RUNTESTFLAGS="c.exp='icv-6.c' c++.exp='icv-6.c'"
fails.
The thing is that the testcase as written relies on OMP_NUM_THREADS not being
set in environment (as it takes priority over OMP_NUM_THREADS_ALL for the
host).
So, if either a user has OMP_NUM_THREADS=42 in the environment by himself, or
when doing make check with -jN, we trigger:
if test $$num_cpus -gt 8 && test -z "$$OMP_NUM_THREADS"; then \
OMP_NUM_THREADS=8; export OMP_NUM_THREADS; \
echo @@@ libgomp OMP_NUM_THREADS adjusted to 8 because of parallel
make check and too many CPUs; \
fi; \
in libgomp/testsuite/Makefile.am and so the test fails.
So, I think we need something like:
--- libgomp/testsuite/libgomp.c-c++-common/icv-6.c.jj 2022-09-08
20:22:07.903182970 +0200
+++ libgomp/testsuite/libgomp.c-c++-common/icv-6.c 2022-09-09
16:49:29.442195701 +0200
@@ -17,6 +17,7 @@
#include
#include
+#include
int
main ()
@@ -25,21 +26,28 @@ main ()
int chunk_size;
omp_get_schedule(&kind, &chunk_size);
- if (omp_get_max_teams () != 42
- || !omp_get_dynamic ()
- || kind != 3 || chunk_size != 4
- || omp_get_teams_thread_limit () != 44
- || omp_get_thread_limit () != 45
- || omp_get_max_threads () != 46
- || omp_get_proc_bind () != omp_proc_bind_spread
- || omp_get_max_active_levels () != 47)
+ if ((!getenv ("OMP_NUM_TEAMS") && omp_get_max_teams () != 42)
+ || (!getenv ("OMP_DYNAMIC") && !omp_get_dynamic ())
+ || (!getenv ("OMP_SCHEDULE") && (kind != 3 || chunk_size != 4))
+ || (!getenv ("OMP_TEAMS_THREAD_LIMIT") && omp_get_teams_thread_limit ()
!= 44)
+ || (!getenv ("OMP_THREAD_LIMIT") && omp_get_thread_limit () != 45)
+ || (!getenv ("OMP_NUM_THREADS") && omp_get_max_threads () != 46)
+ || (!getenv ("OMP_PROC_BIND") && omp_get_proc_bind () !=
omp_proc_bind_spread)
+ || (!getenv ("OMP_MAX_ACTIVE_LEVELS") && omp_get_max_active_levels () !=
47))
abort ();
int num_devices = omp_get_num_devices () > 3 ? 3 : omp_get_num_devices ();
- for (int i=0; i < num_devices; i++)
+ for (int i = 0; i < num_devices; i++)
+{
+ char name[sizeof ("OMP_NUM_TEAMS_DEV_0")];
+ strcpy (name, "OMP_NUM_TEAMS_DEV_0");
+ name[sizeof ("OMP_NUM_TEAMS_DEV_0") - 2] = '0' + i;
+ if (getenv (name))
+ continue;
#pragma omp target device (i)
if (omp_get_max_teams () != 43)
abort ();
+}
return 0;
}
or if we say users are on their own if they make check with any OMP_*
environment variables,
then at least do that for OMP_NUM_THREADS because we set it ourselves.
[Bug tree-optimization/106896] New: [13 Regression] ICE in to_sreal_scale, at profile-count.cc:339
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106896
Bug ID: 106896
Summary: [13 Regression] ICE in to_sreal_scale, at
profile-count.cc:339
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc 13.0.0 20220904 snapshot (g:20d30e737ad79dc36817e59f1676aa8bc0c6b325) ICEs
when compiling the following testcase w/ -O2:
int m, n;
__attribute__ ((cold)) void
bar (void);
void
foo (int *p)
{
m = 1;
while (m > 0)
{
for (n = 0; n < 2; ++n)
{
}
bar ();
while (m > 0)
{
}
}
*p = 0;
*p = m;
}
% gcc-13.0.0 -O2 -c mqgbo1aa.c
during GIMPLE pass: slp
mqgbo1aa.c: In function 'foo':
mqgbo1aa.c:7:1: internal compiler error: in to_sreal_scale, at
profile-count.cc:339
7 | foo (int *p)
| ^~~
0x72c105 profile_count::to_sreal_scale(profile_count, bool*) const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/profile-count.cc:339
0x11acae2 vect_slp_node_weight
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/tree-vect-slp.cc:329
0x11acae2 vect_optimize_slp_pass::start_choosing_layouts()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/tree-vect-slp.cc:4684
0x11ad92b vect_optimize_slp_pass::run()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/tree-vect-slp.cc:5545
0x11ada40 vect_optimize_slp(vec_info*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/tree-vect-slp.cc:5568
0x11ada40 vect_optimize_slp(vec_info*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/tree-vect-slp.cc:5564
0x11b5a9c vect_slp_analyze_bb_1
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/tree-vect-slp.cc:7289
0x11b5a9c vect_slp_region
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/tree-vect-slp.cc:7377
0x11b74db vect_slp_bbs
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/tree-vect-slp.cc:7568
0x11b7783 vect_slp_function(function*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/tree-vect-slp.cc:7656
0x11c06a1 execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/tree-vectorizer.cc:1532
[Bug c++/106880] [12/13 Regression] "error: use of deleted function" printed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106880 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug middle-end/106833] Miss to handle OPAQUE_TYPE specially in verify_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833 --- Comment #13 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:e230f11e9784eefed316df7dbc5df6ac999841b2 commit r13-2562-ge230f11e9784eefed316df7dbc5df6ac999841b2 Author: Kewen Lin Date: Fri Sep 9 08:17:21 2022 -0500 Handle OPAQUE_TYPE specially in verify_type [PR106833] As PR106833 shows, cv-qualified opaque type can cause ICE during LTO. It exposes that we missd to handle OPAQUE_TYPE well in type verification. As Richi pointed out, also assuming that target will always define TYPE_MAIN_VARIANT TYPE_CANONICAL for opaque type, this patch is to check both are OPAQUE_TYPE_P and their modes are of MODE_OPAQUE class. Besides, it also checks the only available size and alignment information. PR middle-end/106833 gcc/ChangeLog: * tree.cc (verify_opaque_type): New function. (verify_type): Call verify_opaque_type for OPAQUE_TYPE. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr106833.c: New test.
[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106894 --- Comment #4 from Marcel Vollweiler --- Thanks Jakub! Although I checked for regressions, unfortunately I haven't seen this regression due to the dg-set-target-env-var topic. I assume that the icv-6.c test FAIL is caused by some other issue (your patch fixes the issue when multiple values are defind for OMP_PROC_BIND that is not the case in icv-6.c). So, I will have another look at icv-6.c ASAP.
[Bug middle-end/106892] [11/12/13 Regression] Wrong code at -O3 on x86_64-linux-gnu since r11-963-g80d6f89e78fc3b77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892 --- Comment #11 from Richard Biener --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a8b0b13da7379feb31950a9d2ad74b98a29c547f commit r13-2560-ga8b0b13da7379feb31950a9d2ad74b98a29c547f Author: Richard Biener Date: Fri Sep 9 12:06:38 2022 +0200 tree-optimization/106722 - avoid invalid pointer association in predcom When predictive commoning builds a reference for iteration N it prematurely associates a constant offset into the MEM_REF offset operand which can be invalid if the base pointer then points outside of an object which alias-analysis does not consider valid. PR tree-optimization/106722 * tree-predcom.cc (ref_at_iteration): Do not associate the constant part of the offset into the MEM_REF offset operand, across a non-zero offset. * gcc.dg/torture/pr106892.c: New testcase.
[Bug tree-optimization/106722] bogus uninit warning in tree-vect-loop-manip.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106722 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a8b0b13da7379feb31950a9d2ad74b98a29c547f commit r13-2560-ga8b0b13da7379feb31950a9d2ad74b98a29c547f Author: Richard Biener Date: Fri Sep 9 12:06:38 2022 +0200 tree-optimization/106722 - avoid invalid pointer association in predcom When predictive commoning builds a reference for iteration N it prematurely associates a constant offset into the MEM_REF offset operand which can be invalid if the base pointer then points outside of an object which alias-analysis does not consider valid. PR tree-optimization/106722 * tree-predcom.cc (ref_at_iteration): Do not associate the constant part of the offset into the MEM_REF offset operand, across a non-zero offset. * gcc.dg/torture/pr106892.c: New testcase.
[Bug target/106895] powerpc64 strange extended inline asm behaviour with register pairs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||meissner at gcc dot gnu.org --- Comment #2 from Peter Bergner --- Using the type __int128 will give you a register pair, but will not guarantee an even/odd pair. The "r" constraint will make sure you have a GPR, but again, doesn't give you an even register. Looking through our backend, we seem to use the wQ constraint internally when generating the stq insn. You could try that. Mike, is that the correct thing to use here to get an even/odd GPR pair?
[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106894 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed now.
[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106894 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:26a1f4fcb264d110708483815c8c8d7bb4ff6788 commit r13-2559-g26a1f4fcb264d110708483815c8c8d7bb4ff6788 Author: Jakub Jelinek Date: Fri Sep 9 13:43:43 2022 +0200 libgomp: Fix up OMP_PROC_BIND handling [PR106894] While the first param is char (gomp_global_icv.bind_var), the second param is char * (gomp_bind_var_list), so we shouldn't access it through *(char *). 2022-09-09 Jakub Jelinek PR libgomp/106894 * env.c (initialize_env) : Use char ** instead of char * for dest[1] initialization from params[1]. Formatting fixes.
[Bug c/106895] powerpc64 strange extended inline asm behaviour with register pairs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895 --- Comment #1 from Richard Biener --- I'm quite sure that 'r' is the wrong constraint letter here.
[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106894 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-09-09 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 53556 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53556&action=edit gcc13-pr106894.patch Lightly tested fix.
[Bug c/106895] New: powerpc64 strange extended inline asm behaviour with register pairs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
Bug ID: 106895
Summary: powerpc64 strange extended inline asm behaviour with
register pairs
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: npiggin at gmail dot com
CC: segher at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux-gnu
This is Debian 12.2.0-1 build.
powerpc64 instructions operating on 128 bits use "even/odd pair" of adjacent
GPRs, where the lower numbered register specifies the pair and it must be an
even number. This code compiled with -O2:
void set128(__int128 val, __int128 *mem)
{
#if WORKAROUND
asm("");
#endif
asm("stq %1,%0" : "=m"(*mem) : "r"(val));
}
Results in an invalid even/odd pair:
stq 3,0(5)
blr
If compiled with -DWORKAROUND it results in a valid pair:
mr 10,3
mr 11,4
stq 10,0(5)
blr
[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 Richard Biener changed: What|Removed |Added Target|x86_64-*-*, i?86-*-*|x86_64-*-*, i?86-*-*, ||aarch64, alpha, arm, ia64, ||loongarch, mips, sparc Keywords||documentation --- Comment #18 from Richard Biener --- I'll note that I can't find any documentation for this link-time behavior which triggers for -Ofast, -ffast-math and -funsafe-math-optimizations but also with -ffast-math -fno-unsafe-math-optimizations. I've adjusted the list of affected targets. What their crtfastmath.o actually does would need to be determined, but it for sure will have the same spreading effect.
[Bug c++/106893] [12/13 Regression] auto deduces wrong type for function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106893 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- Started with r12-1270: c++: alias member template [PR100102] Patrick already fixed the primary cause of this bug. But while I was looking at this testcase I noticed that with the qualified name k::o we ended up with a plain FUNCTION_DECL, whereas without the k:: we got a BASELINK. There seems to be no good reason not to return the BASELINK in this case as well.
[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #17 from Richard Biener --- Note that when a shared library wants -ffast-math like behavior (FTZ, etc.) _not_ linking crtfastmath.o will cause its behavior to depend on the process loading it and whether that sets the appropriate flags or not. That might also cause highly surprising effects. That said, a "true fix" would redesign how these things work and make FTZ part of the instruction encoding. I suppose setting/restoring the control word around all public API of a translation unit (and with LTO a bit more optimized) would be prohibitly expensive. Short of dropping the feature or re-implementing it, for example in the dynamic loader via some ELF annotations with documented behavior on "mismatch", I don't see any fix for this bug besides asking users to conciously not link with -ffast-math when building shared libraries - unless that's intended.
[Bug middle-end/106892] [11/12/13 Regression] Wrong code at -O3 on x86_64-linux-gnu since r11-963-g80d6f89e78fc3b77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892 --- Comment #10 from Richard Biener --- So it's aready dataref analysis that tears apart the constant offset for dr.innermost, here as DR_BASE_ADDRESS &f DR_OFFSET (ssizetype) ((sizetype) prephitmp_80 * 18446744073709551612) DR_INIT 16 but ref_at_iteration associates that in an invalid way. I'm testing a patch.
[Bug tree-optimization/106860] [12 Regression] ICE in single_pred_edge, at basic-block.h:347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106860 Richard Biener changed: What|Removed |Added Known to work||12.2.1 Resolution|--- |FIXED Known to fail||12.2.0 Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug c++/106841] [12 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1509 since r12-2733-g31855ba6b16cd138
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106841 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||12.2.1 Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug tree-optimization/106809] [12 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106809 Richard Biener changed: What|Removed |Added Known to fail||12.2.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||12.2.1 --- Comment #12 from Richard Biener --- Fixed.
[Bug c++/106841] [12 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1509 since r12-2733-g31855ba6b16cd138
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106841 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:41b4faa130a32b37debb1f92e3fa93b2fe8571fc commit r12-8752-g41b4faa130a32b37debb1f92e3fa93b2fe8571fc Author: Richard Biener Date: Tue Sep 6 10:08:44 2022 +0200 tree-optimization/106841 - gather and hybrid SLP Hybrid SLP detection currently fails to consider a not direct offset operand of a scatter/gather operation. The following fixes this. PR tree-optimization/106841 * tree-vect-slp.cc (vect_detect_hybrid_slp): Also process scatter/gather offset. * g++.dg/vect/pr106841.cc: New testcase. (cherry picked from commit e33e61d417eb5e981bb7d709f8681a2f55ed518a)
[Bug tree-optimization/106860] [12 Regression] ICE in single_pred_edge, at basic-block.h:347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106860 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:4ce316ca54c863cf0fd4257ba0ab768ab83c62e5 commit r12-8753-g4ce316ca54c863cf0fd4257ba0ab768ab83c62e5 Author: Richard Biener Date: Wed Sep 7 10:44:33 2022 +0200 tree-optimization/106860 - fix profile scaling in split_loop The following fixes a mistake in loop splitting which assumes loop latches have a single predecessor and that edge is from the exit test. Instead work from the single exit edge we have to find the edge towards the latch. PR tree-optimization/106860 * tree-ssa-loop-split.cc (split_loop): Find the exit to latch edge from the loop exit edge instead of from the latch. Verify we're going to find it. * g++.dg/opt/pr106860.C: New testcase. (cherry picked from commit 0386609923577e07354ee63754795b2f729e7e00)
[Bug tree-optimization/106809] [12 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106809 --- Comment #11 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:e08dd36f90e74cd5be615b1ca82a38896434d48c commit r12-8751-ge08dd36f90e74cd5be615b1ca82a38896434d48c Author: Richard Biener Date: Fri Sep 2 13:36:13 2022 +0200 tree-optimization/106809 - compile time hog in VN The dominated_by_p_w_unex function is prone to high compile time. With GCC 12 we introduced a VN run for uninit diagnostics which now runs into a degenerate case with bison generated code. Fortunately this case is easy to fix with a simple extra check - a more general fix needs more work. PR tree-optimization/106809 * tree-ssa-sccvn.cc (dominaged_by_p_w_unex): Check we have more than one successor before doing extra work. * gcc.dg/torture/pr106809.c: New testcase. (cherry picked from commit be1b42de9c151d46c89f9a8f82d4c5839a19ea94)
[Bug tree-optimization/106881] [13 Regression] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740 since r13-2500-g0a4a2667dc115ca7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106881 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #14 from Richard Biener --- Fixed.
[Bug tree-optimization/106881] [13 Regression] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740 since r13-2500-g0a4a2667dc115ca7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106881 --- Comment #13 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:923da63e0f69b091014df5cc91498756053b1a46 commit r13-2557-g923da63e0f69b091014df5cc91498756053b1a46 Author: Richard Biener Date: Fri Sep 9 09:56:45 2022 +0200 tree-optimization/106881 - fix simple_control_dep_chain part This adjusts simple_control_dep_chain in the same way I adjusted compute_control_dep_chain_pdom to avoid adding fallthru edges to the predicate chain. PR tree-optimization/106881 * gimple-predicate-analysis.cc (simple_control_dep_chain): Add only non-fallthru edges and avoid the same set of edges as compute_control_dep_chain_pdom does.
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652
Jakub Jelinek changed:
What|Removed |Added
Attachment #53508|0 |1
is obsolete||
--- Comment #8 from Jakub Jelinek ---
Created attachment 53555
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53555&action=edit
gcc13-pr106652-wip.patch
Some further progress. Introduces a helper extended_float_type_p and uses it
and attempts to implement 2) from above and add some testcase coverage for it
(not complete, because right now there are just float{16,32,64,128} effective
targets and not effective targets for various float/double/long double type
properties (e.g. if they are ieee type), so for the cases where there should be
an error on the conversion I've kept only cases where I know for sure using the
above mentioned effective targets, not where it is sometimes the case and
sometimes it isn't. From the above list, 1) needs decision what to do about
arithmetics in that type, 4) needs discussion on where to diagnose it, 5) needs
implementation.
[Bug middle-end/106892] [11/12/13 Regression] Wrong code at -O3 on x86_64-linux-gnu since r11-963-g80d6f89e78fc3b77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892 --- Comment #9 from Richard Biener --- So the reason is that we have # RANGE [-2147483643, 2] _137 = 4 - prephitmp_80; f[_137] = _139; which makes us conclude the f[_137] access is constrained to f[0..2]. When we see _75 = MEM[(int *)_20 + 16B]; we then disambiguate because iff _20 points into 'f' then with offset 16 it's beyond that constrained access. _But_! # RANGE [18446744065119617028, 18446744073709551608] _5 = _39 * -4U; # PT = anything _20 = &f + _5; _20 is actually _before_ 'f' which we consider invalid. Now here's what the frontend presents us with: f[4 - d] = f[4 - d] ^ 3; which we eventually gimplify to _5 = 4 - d.1_4; _6 = f[_5]; but then predictive commoning comes along: Load motion chain 0x43bb3d0 inits MEM[(int *)_20 + 16B] references: f[_2] (id 0) offset 0 distance 0 f[_2] (id 1, write) offset 0 distance 0 Executing predictive commoning without unrolling [local count: 35740571]: + _39 = (sizetype) prephitmp_80; + _5 = _39 * 18446744073709551612; + _20 = &f + _5; + _75 = MEM[(int *)_20 + 16B]; [local count: 289173710]: # ivtmp_48 = PHI + # f_I_lsm0.27_12 = PHI _2 = 4 - prephitmp_80; - _3 = f[_2]; + _3 = f_I_lsm0.27_12; introducing this kind of problem. We have a "opt-out" with using TARGET_MEM_REF which is exempt from this rule because IVOPTs also likes to break it.
[Bug middle-end/106892] [11/12/13 Regression] Wrong code at -O3 on x86_64-linux-gnu since r11-963-g80d6f89e78fc3b77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #8 from Richard Biener ---
-fno-gcse-lm fixes the testcase. The only difference from the bisected
revision is
(insn 56 55 57 15 (set (mem:SI (plus:DI (mult:DI (reg:DI 102)
(const_int 4 [0x4]))
-(reg/f:DI 99)) [1 f S4 A32])
+(reg/f:DI 99)) [1 f[_137]+0 S4 A32])
(reg:SI 105)) "t.c":19:21 -1
(nil))
and PRE then does
-PRE GCSE of j, 23 basic blocks, 3800 bytes needed, 0 substs, 0 insns created
+scanning new insn with uid = 106.
+deleting insn with uid = 54.
+PRE: redundant insn 54 (expression 5) in bb 15, reaching reg is 107
+PRE: edge (14,15), copy expression 5
+scanning new insn with uid = 107.
+PRE GCSE of j, 23 basic blocks, 3848 bytes needed, 1 substs, 1 insns created
it looks like RTL PRE hoists
(insn 54 50 55 15 (set (reg:SI 106 [ MEM[(int *)_20 + 16B] ])
(mem:SI (plus:DI (reg/f:DI 86 [ _20 ])
(const_int 16 [0x10])) [1 MEM[(int *)_20 + 16B]+0 S4 A32]))
"t.c":19:21 67 {*movsi_internal}
(nil))
out of the loop, across
(insn 56 55 57 15 (set (mem:SI (plus:DI (mult:DI (reg:DI 102)
(const_int 4 [0x4]))
(symbol_ref:DI ("f") [flags 0x2] ))
[1 f[_137]+0 S4 A32])
(reg:SI 105)) "t.c":19:21 67 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 105)
(expr_list:REG_DEAD (reg:DI 102)
(expr_list:REG_DEAD (reg/f:DI 99)
(nil)
I will see why exactly.
[Bug tree-optimization/106881] [13 Regression] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740 since r13-2500-g0a4a2667dc115ca7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106881 --- Comment #12 from rguenther at suse dot de --- On Fri, 9 Sep 2022, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106881 > > Martin Li?ka changed: > >What|Removed |Added > > Resolution|FIXED |--- > Status|RESOLVED|REOPENED > > --- Comment #11 from Martin Li?ka --- > Confirmed, reducing that right now.. I'm already testing the obvious patch - reduction will be iffy because you need to run into compile-time limits to get the fallback implementation triggering ...
[Bug middle-end/106892] [11/12/13 Regression] Wrong code at -O3 on x86_64-linux-gnu since r11-963-g80d6f89e78fc3b77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892 Richard Biener changed: What|Removed |Added Component|c |middle-end Target Milestone|--- |11.4
[Bug c/106892] [11/12/13 Regression] Wrong code at -O3 on x86_64-linux-gnu since r11-963-g80d6f89e78fc3b77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892
--- Comment #7 from Richard Biener ---
So the inline just has the return undefined in the unreachable path. We can
make the inlined functions static (cleans up post-IPA dumps) and disable IPA
for j:
int a, b, c, d, e;
int f[8];
static int g() {
while (a)
a >>= 4;
return 0;
}
static int h(int i) {
if (i >= '0')
return i - '0';
//__builtin_unreachable ();
}
void __attribute__((noipa)) j(int i) {
for (b = 2; g() <= 7; b++)
if (i) {
for (; e <= 7; e++)
for (c = 1; c <= 7; c++) {
d = h(b + '0');
f[-d + 4] ^= 3;
}
return;
}
}
int main() {
j(1);
if (f[2] != 0)
__builtin_abort ();
}
[Bug tree-optimization/106881] [13 Regression] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740 since r13-2500-g0a4a2667dc115ca7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106881 Martin Liška changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #11 from Martin Liška --- Confirmed, reducing that right now..
[Bug c/106892] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892
--- Comment #6 from Jakub Jelinek ---
I would clean it even more:
int a, b, c, d, e;
int f[8];
int g() {
while (a)
a >>= 4;
return 0;
}
int h(int i) {
if (i >= '0')
return i - '0';
//__builtin_unreachable ();
}
void j(int i) {
for (b = 2; g() <= 7; b++)
if (i) {
for (; e <= 7; e++)
for (c = 1; c <= 7; c++) {
d = h(b + '0');
f[-d + 4] ^= 3;
}
return;
}
}
int main() {
j(1);
if (f[2] != 0)
__builtin_abort ();
}
so that a) it isn't ASCII specific and misbehaves for EBCDIC etc., and b)
undoes what creduce/cvise likes to do, moving expressions from for init
expression before the loop
[Bug c/106892] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892
--- Comment #5 from Martin Liška ---
Clean up test-case:
$ cat pr106892.c
int a, b, c, d, e;
int f[8];
int
g() {
while (a)
a >>= 4;
return 0;
}
int
h(int i) {
if (i >= '0')
return i - '0';
}
void
j(int i) {
b = 2;
for (; g() <= 7; b++)
if (i) {
for (; e <= 7; e++) {
c = 1;
for (; c <= 7; c++) {
d = h(b + 48);
f[-d + 4] ^= 3;
}
}
return;
}
}
int
main() {
j(1);
__builtin_printf("%d\n", f[2]);
if (f[2] != 0)
__builtin_abort ();
return 0;
}
Started to print '3' since r11-963-g80d6f89e78fc3b77.
[Bug c/106892] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
CC||rguenth at gcc dot gnu.org
Keywords||wrong-code
--- Comment #4 from Richard Biener ---
(In reply to Li Shaohua from comment #3)
> Yes, I reduced it too much. Here is the new one with return value in g()
> function.
>
> a, b, c, d, e;
> f[8];
> g() {
> while (a)
> a >>= 4;
> return 0;
> }
> h(i) {
> if (i >= '0')
> return i - '0';
> }
> j(i) {
> b = 2;
> for (; g() <= 7; b++)
> if (i) {
> for (; e <= 7; e++) {
> c = 1;
> for (; c <= 7; c++) {
> d = h(b + 48);
> f[-d + 4] ^= 3;
> }
> }
> return;
> }
> }
> main() {
> j(1);
> printf("%d\n", f[2]);
> }
When I apply the same "fix" to h() (add a return 0 or __builtin_unreachable ())
the code works again.
Note I think the missing return stmt isn't reached at runtime.
Disabling either unswitching or loop splitting makes the issue go away,
enabling both ontop of -O2 doesn't trigger it.
We early inline h into j where h looks like
int h (int i)
{
int _3;
:
if (i_1(D) > 47)
goto ; [INV]
else
goto ; [INV]
:
_3 = i_1(D) + -48;
// predicted unlikely by early return (on trees) predictor.
return _3;
:
return;
}
which results in
b.2_1 = b;
_2 = b.2_1 + 48;
_3 = h (_2);
d = _3;
becoming
b.2_1 = b;
_2 = b.2_1 + 48;
if (_2 > 47)
goto ; [34.00%]
else
goto ; [66.00%]
:
_30 = _2 + -48;
_43 = _30;
:
# _39 = PHI <_43(6), _37(5)>
_3 = _39;
d = _3;
note that the return; case results in _37 to be used which is completely
random.
That said, our handling of an unreachable missing return in the IL is
likely counter productive.
Cleaned up testcase:
int a, b, c, d, e;
int f[8];
int g() {
while (a)
a >>= 4;
return 0;
}
int h(int i) {
if (i >= '0')
return i - '0';
//__builtin_unreachable ();
}
void j(int i) {
b = 2;
for (; g() <= 7; b++)
if (i) {
for (; e <= 7; e++) {
c = 1;
for (; c <= 7; c++) {
d = h(b + 48);
f[-d + 4] ^= 3;
}
}
return;
}
}
int main() {
j(1);
if (f[2] != 0)
__builtin_abort ();
}
[Bug c/106892] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892
--- Comment #3 from Li Shaohua ---
Yes, I reduced it too much. Here is the new one with return value in g()
function.
a, b, c, d, e;
f[8];
g() {
while (a)
a >>= 4;
return 0;
}
h(i) {
if (i >= '0')
return i - '0';
}
j(i) {
b = 2;
for (; g() <= 7; b++)
if (i) {
for (; e <= 7; e++) {
c = 1;
for (; c <= 7; c++) {
d = h(b + 48);
f[-d + 4] ^= 3;
}
}
return;
}
}
main() {
j(1);
printf("%d\n", f[2]);
}
[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106894 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c/106892] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-09-09 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #2 from Richard Biener --- possibly too much reduced?
[Bug tree-optimization/106881] [13 Regression] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740 since r13-2500-g0a4a2667dc115ca7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106881 --- Comment #10 from David Binderman --- Created attachment 53554 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53554&action=edit gzipped C++ source code The attached C++ code, after Richard's fix, seems to break gcc. Flags -O1 -Wall required.
