[Bug tree-optimization/104010] [12 regression] short loop no longer vectorized with Neon after r12-3362
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||missed-optimization
[Bug testsuite/104022] New: g++.dg/gcov/pr16855.C does not precleanup upon failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104022
Bug ID: 104022
Summary: g++.dg/gcov/pr16855.C does not precleanup upon
failures
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: rimvydas.jas at gmail dot com
Target Milestone: ---
Created attachment 52186
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52186&action=edit
xfails
Testsuite on x86_64-*-dragonfly gives:
$ gmake check-gcc-c++ -k RUNTESTFLAGS="gcov.exp=pr16855*"
FAIL: g++.dg/gcov/pr16855-priority.C -std=gnu++98 line 14: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C -std=gnu++98 line 21: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C -std=gnu++98 line 22: is #:should be
1
FAIL: g++.dg/gcov/pr16855-priority.C -std=gnu++98 line 35: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C -std=gnu++98 line 41: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C -std=gnu++98 line 46: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C -std=gnu++98 line 51: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C -std=gnu++98 line 56: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C -std=gnu++98 line 61: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C -std=gnu++98 line 66: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C -std=gnu++98 line 71: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C -std=gnu++98 line 76: is 5:should be 1
FAIL: g++.dg/gcov/pr16855-priority.C -std=gnu++98 gcov: 12 failures in line
counts, 0 in branch percentages, 0 in return percentages, 0 in intermediate
format
[SNIP]
FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 line 15: is 5:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 line 22: is 5:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 line 24: is #:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 line 38: is 5:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 line 44: is 5:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 line 49: is 5:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 gcov: 6 failures in line counts, 0
in branch percentages, 0 in return percentages, 0 in intermediate format
FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 line 15: is 6:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 line 22: is 6:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 line 24: is #:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 line 38: is 6:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 line 44: is 6:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 line 49: is 6:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 gcov: 6 failures in line counts, 0
in branch percentages, 0 in return percentages, 0 in intermediate format
FAIL: g++.dg/gcov/pr16855.C -std=gnu++17 line 15: is 7:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++17 line 22: is 7:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++17 line 24: is #:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++17 line 38: is 7:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++17 line 44: is 7:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++17 line 49: is 7:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++17 gcov: 6 failures in line counts, 0
in branch percentages, 0 in return percentages, 0 in intermediate format
FAIL: g++.dg/gcov/pr16855.C -std=gnu++2a line 15: is 8:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++2a line 22: is 8:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++2a line 24: is #:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++2a line 38: is 8:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++2a line 44: is 8:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++2a line 49: is 8:should be 1
FAIL: g++.dg/gcov/pr16855.C -std=gnu++2a gcov: 6 failures in line counts, 0
in branch percentages, 0 in return percentages, 0 in intermediate format
=== g++ Summary ===
# of expected passes24
# of unexpected failures80
/build/trunk/gcc/xg++ version 12.0.0 20220114 (experimental)
[remotes/origin/master -gb31cec9c22b] (GCC)
Line counts are incrementing with every check command invoke. Adding missing
xfails avoids the issue.
$ gmake check-gcc-c++ -k RUNTESTFLAGS="gcov.exp=pr16855*"
=== g++ Summary ===
# of expected passes88
# of expected failures 16
The "line 24: is #:should be 1" is a known issue on DragonFly BSD, the
dynamic linker on dso stops profiling before destructor is executed.
Alternatively adding "/* { dg-additional-options "-static" { target
*-*-dragonfly* } } */" directives to both tests allows them to pass fully.
# of expected passes104
[Bug testsuite/104021] New: gcc.dg/vect/tsvc tests failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104021 Bug ID: 104021 Summary: gcc.dg/vect/tsvc tests failures Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: rimvydas.jas at gmail dot com Target Milestone: --- Created attachment 52185 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52185&action=edit simple fix Testsuite on x86_64-*-dragonfly gives: $ gmake check-gcc-c -k RUNTESTFLAGS="vect.exp=vect-tsvc*" Running /zzz/gg/gcc/testsuite/gcc.dg/vect/vect.exp ... FAIL: gcc.dg/vect/tsvc/vect-tsvc-s000.c (test for excess errors) FAIL: gcc.dg/vect/tsvc/vect-tsvc-s111.c (test for excess errors) [SNIP] FAIL: gcc.dg/vect/tsvc/vect-tsvc-vtv.c -flto -ffat-lto-objects (test for excess errors) FAIL: gcc.dg/vect/tsvc/vect-tsvc-vtvtv.c -flto -ffat-lto-objects (test for excess errors) Excess errors: /data/gg/gcc/testsuite/gcc.dg/vect/tsvc/tsvc.h:15:10: fatal error: malloc.h: No such file or directory === gcc Summary === # of unexpected failures302 # of unresolved testcases 604 /build/trunk/gcc/xgcc version 12.0.0 20220114 (experimental) [remotes/origin/master -gb31cec9c22b] (GCC) The DragonFly BSD does not have nor memalign(3), but posix_memalign(3) is available. With patch applied: $ gmake check-gcc-c -k RUNTESTFLAGS="vect.exp=vect-tsvc*" === gcc Summary === # of expected passes736 # of expected failures 170
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 --- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE --- > A quick parallel make configure-target-libgfortran all-target-libfortran > completed without issues. I've just fired off full bootstraps with that > patch before going to bed. Those completed successfully, too.
[Bug c++/104020] New: [coroutines] ICE in co_await function call with initializer_list arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104020
Bug ID: 104020
Summary: [coroutines] ICE in co_await function call with
initializer_list arguments
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at xecycle dot info
Target Milestone: ---
Running example at https://godbolt.org/z/cEjTWPvYf, code with clang part
removed is:
#include
using std::coroutine_handle;
using std::suspend_always;
using std::suspend_never;
#include
#include
struct promise_t;
struct ret_t {
using promise_type = promise_t;
};
struct promise_t {
ret_t get_return_object() { return {}; }
constexpr auto initial_suspend() noexcept { return suspend_never(); }
void return_void() {}
auto final_suspend() noexcept { return suspend_never(); }
void unhandled_exception()
{
__builtin_trap();
}
};
auto operator co_await(ret_t)
{
struct W {
auto await_ready() { return std::true_type(); }
void await_suspend(coroutine_handle<>) {}
void await_resume() {}
};
return W();
}
ret_t f1(std::initializer_list)
{
co_return;
}
ret_t f2()
{
co_await f1({"abc", "def"});
}
ICE in 11.2, "array used as initializer" in trunk.
Can compile if either:
- the argument is std::initializer_list, or
- use a separate variable, like
std::initializer_list args {"abc", "def"};
co_await f1(args);
[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||rguenth at gcc dot gnu.org,
||rsandifo at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #2 from Kewen Lin ---
With further investigation, this isn't duplicated. Now we have the function
partial_vectors_supported_p to get boolean supports_partial_vectors.
on rs6000, it's:
bool
partial_vectors_supported_p (void)
{
return HAVE_len_load_v16qi || HAVE_len_store_v16qi;
}
#define HAVE_len_load_v16qi (TARGET_P9_VECTOR && TARGET_64BIT)
#define HAVE_len_store_v16qi (TARGET_P9_VECTOR && TARGET_64BIT)
The above optabs are supported from Power9 already.
However, we only enable it from Power10 due to known performance issue on
Power9.
/* The lxvl/stxvl instructions don't perform well before Power10. */
if (TARGET_POWER10)
SET_OPTION_IF_UNSET (&global_options, &global_options_set,
param_vect_partial_vector_usage, 1);
else
SET_OPTION_IF_UNSET (&global_options, &global_options_set,
param_vect_partial_vector_usage, 0);
So checking optab supports look not robust.
I had a check with the below fix, it works:
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index ba67de490bb..49d53fb3383 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -3026,7 +3026,8 @@ vect_analyze_loop (class loop *loop, vec_info_shared
*shared)
vector_modes[0] = autodetected_vector_mode;
mode_i = 0;
- bool supports_partial_vectors = partial_vectors_supported_p ();
+ bool supports_partial_vectors =
+partial_vectors_supported_p () && param_vect_partial_vector_usage != 0;
poly_uint64 first_vinfo_vf = LOOP_VINFO_VECT_FACTOR (first_loop_vinfo);
while (1)
But, is there some reason not use the LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P of
first_loop_vinfo? It respects param_vect_partial_vector_usage and checks
partial vector supports (LOOP_VINFO_MASKS and LOOP_VINFO_LENS) during the
analysis phase, it looks good fit for this need of supports_partial_vectors.
[Bug libstdc++/104019] New: Testsuite 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019 Bug ID: 104019 Summary: Testsuite 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc failures Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rimvydas.jas at gmail dot com Target Milestone: --- Testsuite on x86_64-*-dragonfly gives: Running target unix FAIL: 17_intro/headers/c++1998/stdc++.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/stdc++_multiple_inclusion.cc (test for excess errors) FAIL: 17_intro/headers/c++2011/stdc++.cc (test for excess errors) FAIL: 17_intro/headers/c++2011/stdc++_multiple_inclusion.cc (test for excess errors) FAIL: 17_intro/headers/c++2014/stdc++.cc (test for excess errors) FAIL: 17_intro/headers/c++2014/stdc++_multiple_inclusion.cc (test for excess errors) FAIL: 17_intro/headers/c++2017/stdc++.cc (test for excess errors) FAIL: 17_intro/headers/c++2017/stdc++_multiple_inclusion.cc (test for excess errors) Excess errors: /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/shared_ptr_base.h:340: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] FAIL: 17_intro/headers/c++2020/stdc++.cc (test for excess errors) spawn -ignore SIGHUP /build/trunk/./gcc/xg++ -shared-libgcc -B/build/trunk/./gcc -nostdinc++ -L/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/src -L/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/src/.libs -L/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/libsupc++/.libs -B/opt/gcctrunk/x86_64-unknown-dragonfly6.3/bin/ -B/opt/gcctrunk/x86_64-unknown-dragonfly6.3/lib/ -isystem /opt/gcctrunk/x86_64-unknown-dragonfly6.3/include -isystem /opt/gcctrunk/x86_64-unknown-dragonfly6.3/sys-include -fchecking=1 -B/build/trunk/x86_64-unknown-dragonfly6.3/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3 -I/build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include -I/data/gg/libstdc++-v3/libsupc++ -I/data/gg/libstdc++-v3/include/backward -I/data/gg/libstdc++-v3/testsuite/util /data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++_multiple_inclusion.cc -std=gnu++2a -Wall -Wsystem-headers -fdiagnostics-plain-output -S -o stdc++_multiple_inclusion.s In file included from /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:152, from /data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++_multiple_inclusion.cc:25: /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/version:81: warning: "__cpp_lib_exchange_function" redefined In file included from /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:94, from /data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++_multiple_inclusion.cc:25: /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/utility:87: note: this is the location of the previous definition In file included from /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:152, from /data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++_multiple_inclusion.cc:25: /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/version:83: warning: "__cpp_lib_integer_sequence" redefined In file included from /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/stl_pair.h:62, from /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/stl_algobase.h:64, from /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/specfun.h:45, from /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/cmath:1935, from /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:41, from /data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++_multiple_inclusion.cc:25: /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/bits/utility.h:160: note: this is the location of the previous definition In file included from /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:152, from /data/gg/libstdc++-v3/testsuite/17_intro/headers/c++2020/stdc++_multiple_inclusion.cc:25: /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/version:128: warning: "__cpp_lib_as_const" redefined In file included from /build/trunk/x86_64-unknown-dragonfly6.3/libstdc++-v3/include/x86_64-unknown-dragonfly6.3/bits/stdc++.h:94, from /data/gg/libstdc
[Bug target/104001] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-6538-g5f19303ada7db92c155332e7ba317233ca05946b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104001 --- Comment #6 from Hongtao.liu --- Fixed.
[Bug target/104014] [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104014 --- Comment #10 from Hongtao.liu --- Fixed.
[Bug target/104014] [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104014 --- Comment #9 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:b77e3b4e4589e56c01511fabdbaadb029cd47f5c commit r12-6567-gb77e3b4e4589e56c01511fabdbaadb029cd47f5c Author: liuhongt Date: Thu Jan 13 22:51:49 2022 +0800 Fix ICE of unrecognizable insn. [PR target/104001] For define_insn_and_split "*xor2andn": 1. Refine predicate of operands[0] from nonimmediate_operand to register_operand. 2. Remove TARGET_AVX512BW from condition to avoid kmov when TARGET_BMI is not available. gcc/ChangeLog: PR target/104001 PR target/94790 PR target/104014 * config/i386/i386.md (*xor2andn): Refine predicate of operands[0] from nonimmediate_operand to register_operand, remove TARGET_AVX512BW from condition. gcc/testsuite/ChangeLog: * gcc.target/i386/pr104001.c: New test.
[Bug target/104001] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-6538-g5f19303ada7db92c155332e7ba317233ca05946b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104001 --- Comment #5 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:b77e3b4e4589e56c01511fabdbaadb029cd47f5c commit r12-6567-gb77e3b4e4589e56c01511fabdbaadb029cd47f5c Author: liuhongt Date: Thu Jan 13 22:51:49 2022 +0800 Fix ICE of unrecognizable insn. [PR target/104001] For define_insn_and_split "*xor2andn": 1. Refine predicate of operands[0] from nonimmediate_operand to register_operand. 2. Remove TARGET_AVX512BW from condition to avoid kmov when TARGET_BMI is not available. gcc/ChangeLog: PR target/104001 PR target/94790 PR target/104014 * config/i386/i386.md (*xor2andn): Refine predicate of operands[0] from nonimmediate_operand to register_operand, remove TARGET_AVX512BW from condition. gcc/testsuite/ChangeLog: * gcc.target/i386/pr104001.c: New test.
[Bug rtl-optimization/94790] Failure to use andn in specific pattern in which it is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94790 --- Comment #8 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:b77e3b4e4589e56c01511fabdbaadb029cd47f5c commit r12-6567-gb77e3b4e4589e56c01511fabdbaadb029cd47f5c Author: liuhongt Date: Thu Jan 13 22:51:49 2022 +0800 Fix ICE of unrecognizable insn. [PR target/104001] For define_insn_and_split "*xor2andn": 1. Refine predicate of operands[0] from nonimmediate_operand to register_operand. 2. Remove TARGET_AVX512BW from condition to avoid kmov when TARGET_BMI is not available. gcc/ChangeLog: PR target/104001 PR target/94790 PR target/104014 * config/i386/i386.md (*xor2andn): Refine predicate of operands[0] from nonimmediate_operand to register_operand, remove TARGET_AVX512BW from condition. gcc/testsuite/ChangeLog: * gcc.target/i386/pr104001.c: New test.
[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015 Kewen Lin changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||avieira at gcc dot gnu.org, ||linkw at gcc dot gnu.org Last reconfirmed||2022-01-14 --- Comment #1 from Kewen Lin --- I think it's caused by r12-6240, since I only cherry-picked r12-6523 onto it, the issue can be reproduced. It's likely duplicated of PR103997. On Power9, we don't support partial vector so vectorizer should not try to use the same vector mode for the epilogue? gcc/testsuite/gcc.dg/vect/slp-perm-9.c:17:17: note: * Analysis succeeded with vector mode V8HI gcc/testsuite/gcc.dg/vect/slp-perm-9.c:17:17: note: * Choosing vector mode V8HI gcc/testsuite/gcc.dg/vect/slp-perm-9.c:17:17: note: * Re-trying epilogue analysis with vector mode V8HI
[Bug target/104014] [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104014 --- Comment #8 from Hongtao.liu --- Same issue as PR104001
[Bug tree-optimization/104018] Comparison against 0 propagates into other statement causing no-CSE from happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104018 Andrew Pinski changed: What|Removed |Added Known to fail||12.0, 4.1.2 Severity|normal |enhancement
[Bug tree-optimization/104018] New: Comparison against 0 propagates into other statement causing no-CSE from happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104018
Bug ID: 104018
Summary: Comparison against 0 propagates into other statement
causing no-CSE from happening
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
int f(unsigned int a, unsigned int b) {
if (a > 0) {
return a == b;
} else {
return a == b;
}
}
int f2(unsigned int a, unsigned int b) {
if (a > 1) {
return a == b;
} else {
return a == b;
}
}
They should produce the same results but don't currently as in the first case
the >0 is turned into != 0 and then the 0 is propagated into the comparison and
then the comparison in the other BBSs are not able to be CSE'ed with the other
one.
[Bug tree-optimization/104017] unexpeted -Warray-bounds popping a fixed number of std::deque elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104017
--- Comment #1 from Martin Sebor ---
The warning triggers for the clobber statement in bb 43 below. _236 is assumed
to point to the beginning of the block of 512 bytes allocated by new, so
subtracting a positive integer from it or adding one in excess of 512 is
invalid, as is dereferencing the result:
[local count: 118111600]:
...
_229 = operator new (512); >>> _229
...
[local count: 50546886]:
_176 = p.D.20902._M_impl.D.20257._M_finish._M_first;
if (_176 != _229)
goto ; [82.57%]
else
goto ; [17.43%]
[local count: 41736564]:
_236 = ASSERT_EXPR <_229, _229 != _176>; <<< _229
_177 = _236 + 18446744073709551608;
p.D.20951._M_impl.D.20306._M_finish._M_cur = _177;
MEM[(const struct Node * *)_236 + -8B] ={v} {CLOBBER}; <<< -Warray-bounds
goto ; [100.00%]
I view the warning as helpful here (and so not a false positive even) because
the test function assumes the loop inserts at least three elements into the
container. If it doesn't, one of the pop() calls will crash.
A more compelling test case would guard each if the pop() calls to prevent the
crash, like below:
#include
struct Node { Node const * parent = nullptr; };
void func(Node const * n)
{
std::deque p;
Node const * e = n;
while (e != nullptr) {
p.push_front(e);
e = e->parent;
}
if (p.size ())
p.pop_front();
if (p.size ())
p.pop_front();
if (p.size ())
p.pop_back();
}
This test case also triggers a warning, for the same reason: GCC can't
determine the relationship between a deque's internal node pointers and the
result of std::deque::size() (which is a function of the node pointers).
[Bug fortran/99256] ICE in variable_check, at fortran/check.c:1012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99256
--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> (In reply to anlauf from comment #3)
>
> Even simpler fix, as intrinsics do not accept alternate return specifiers:
>
> diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
> index a7ecdb401ef..4e5ec966d94 100644
> --- a/gcc/fortran/intrinsic.c
> +++ b/gcc/fortran/intrinsic.c
> @@ -4420,7 +4420,7 @@ do_sort:
>FOR_EACH_VEC_ELT (dummy_args, idx, f)
> {
>a = ordered_actual_args[idx];
> - if (a && a->label != NULL && f->ts.type)
> + if (a && a->label != NULL)
> {
> gfc_error ("ALTERNATE RETURN not permitted at %L", where);
> return false;
If this survives regression testing, it certainly seems to fall into the
obviously correct category. I think you can commit the patch.
[Bug middle-end/104017] New: unexpeted -Warray-bounds popping a fixed number of std::deque elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104017
Bug ID: 104017
Summary: unexpeted -Warray-bounds popping a fixed number of
std::deque elements
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
I got the following report in my private mail. I file it here for reference
(and my analysis). Although the warning isn't terribly informative I don't
consider it a false positive.
$ cat t.C && g++ -O2 -S -Wall t.C
#include
struct Node { Node const * parent = nullptr; };
void func(Node const * n)
{
std::deque p;
Node const * e = n;
while (e != nullptr) {
p.push_front(e);
e = e->parent;
}
[[maybe_unused]] Node const * b;
p.pop_front();
e = p.front();
p.pop_front();
b = p.back();
p.pop_back();
}
In file included from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++allocator.h:33,
from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocator.h:46,
from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/deque:61,
from t.C:1:
In member function ‘void std::__new_allocator<_Tp>::destroy(_Up*) [with _Up =
const Node*; _Tp = const Node*]’,
inlined from ‘static void std::allocator_traits
>::destroy(allocator_type&, _Up*) [with _Up = const Node*; _Tp = const Node*]’
at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/alloc_traits.h:535:15,
inlined from ‘void std::deque<_Tp, _Alloc>::pop_back() [with _Tp = const
Node*; _Alloc = std::allocator]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_deque.h:1604:28,
inlined from ‘void func(const Node*)’ at t.C:22:15:
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/new_allocator.h:181:11:
warning: array subscript -1 is outside array bounds of ‘const Node* [64]’
[-Warray-bounds]
181 | { __p->~_Up(); }
| ^~~
In member function ‘_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*) [with _Tp = const Node*]’,
inlined from ‘static _Tp* std::allocator_traits
>::allocate(allocator_type&, size_type) [with _Tp = const Node*]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/alloc_traits.h:464:28,
inlined from ‘std::_Deque_base<_Tp, _Alloc>::_Ptr std::_Deque_base<_Tp,
_Alloc>::_M_allocate_node() [with _Tp = const Node*; _Alloc =
std::allocator]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_deque.h:583:26,
inlined from ‘void std::_Deque_base<_Tp,
_Alloc>::_M_create_nodes(_Map_pointer, _Map_pointer) [with _Tp = const Node*;
_Alloc = std::allocator]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_deque.h:684:37,
inlined from ‘void std::_Deque_base<_Tp,
_Alloc>::_M_initialize_map(std::size_t) [with _Tp = const Node*; _Alloc =
std::allocator]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_deque.h:658:19,
inlined from ‘std::_Deque_base<_Tp, _Alloc>::_Deque_base() [with _Tp =
const Node*; _Alloc = std::allocator]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_deque.h:460:26,
inlined from ‘std::deque<_Tp, _Alloc>::deque() [with _Tp = const Node*;
_Alloc = std::allocator]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_deque.h:855:7,
inlined from ‘void func(const Node*)’ at t.C:7:30:
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/new_allocator.h:137:55:
note: at offset -8 into object of size 512 allocated by ‘operator new’
137 | return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n *
sizeof(_Tp)));
| ^
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 --- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #24 from Jakub Jelinek --- > Created attachment 52184 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52184&action=edit > gcc12-pr104006.patch > > Fix. I've added $(version_dep) to BUILT_SOURCES because I thought it is a > generated file like the others (it is), but missed that in the Solaris case it > depends on all those *.lo files, and BUILT_SOURCES is something that should > be done before all-am. So, this patch reverts that part of the change and > instead cleans the $(version_dep) files in clean-local, so that they are ever > removed when make clean/distclean. A quick parallel make configure-target-libgfortran all-target-libfortran completed without issues. I've just fired off full bootstraps with that patch before going to bed. Thanks a lot!
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 --- Comment #24 from Jakub Jelinek --- Created attachment 52184 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52184&action=edit gcc12-pr104006.patch Fix. I've added $(version_dep) to BUILT_SOURCES because I thought it is a generated file like the others (it is), but missed that in the Solaris case it depends on all those *.lo files, and BUILT_SOURCES is something that should be done before all-am. So, this patch reverts that part of the change and instead cleans the $(version_dep) files in clean-local, so that they are ever removed when make clean/distclean.
[Bug fortran/99256] ICE in variable_check, at fortran/check.c:1012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99256
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
Even simpler fix, as intrinsics do not accept alternate return specifiers:
diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
index a7ecdb401ef..4e5ec966d94 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -4420,7 +4420,7 @@ do_sort:
FOR_EACH_VEC_ELT (dummy_args, idx, f)
{
a = ordered_actual_args[idx];
- if (a && a->label != NULL && f->ts.type)
+ if (a && a->label != NULL)
{
gfc_error ("ALTERNATE RETURN not permitted at %L", where);
return false;
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 --- Comment #23 from Jakub Jelinek --- Ah, I finally understand. gfortran.ver-sun is now (newly) in BUILT_SOURCES through $(version_dep). And it depends on all the sources being built: $(libgfortran_la_OBJECTS) $(libgfortran_la_LIBADD)
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 --- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #21 from Jakub Jelinek --- > That is make -j48 from where? > Toplevel, or the libgfortran build dir, or toplevel make -j48 > all-target-libgfortran or make -j48 maybe-all-target-libgfortran? Both make -j48 from toplevel (within a regular bootstrap) and make -j48 all from libgfortran build dir. > From what I can see, toplevel all-target-libgfortran should do make all in the > libgfortran build dir: [...] > and all: in the libgfortran Makefile should be: > all: $(BUILT_SOURCES) config.h > $(MAKE) $(AM_MAKEFLAGS) all-am > (in your case with the ls -l added above it). Right. > Perhaps also above the ls do > echo all in libgfortran, BUILT_SOURCES is $(BUILT_SOUCES) No difference: that output doesn't show up in the log. > What version of GNU make are you using? Usually, it's 4.2.92 in an attempt to avoid make SEGVs I sometimes observed on Solaris 10. However, I tried the same with 4.2.1: same result. > I just don't understand how it could start building the object files etc. > which is done from all-am before actually ensuring all those $(BUILT_SOURCES) > like kinds.h exist. I've attached the log. The first one it builds (after creating selected_int_kind.inc, selected_real_kind.inc, kinds.h, c99_protos.h, fpu-target.h, and ISO_Fortran_binding.h) is bounds.lo.
[Bug tree-optimization/104012] [12 regression] -Wformat-truncation warnings not taking previous length check into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- I'm not able to reproduce a warning for the test case in attachment 52182 with the top of GCC trunk configured for x86_64 at -O2 or -O3 and with -m32. There are three calls to snprintf() in CreateMakeVariable() and for each call GCC determines the output of the %04d directive is exactly four bytes (see the dump produced by -ftree-dump-strlen): /home/buildbot/repos/CMake/Source/cmLocalUnixMakefileGenerator3.cxx:1307: snprintf: objsize = 5, fmtstr = "%04d" Directive 1 at offset 0: "%04d" Result: 4, 4, 4, 4 (4, 4, 4, 4) Directive 2 at offset 4: "", length = 1 Substituting 4 for return value. /home/buildbot/repos/CMake/Source/cmLocalUnixMakefileGenerator3.cxx:1311: snprintf: objsize = 5, fmtstr = "%04d" Directive 1 at offset 0: "%04d" Result: 4, 4, 4, 4 (4, 4, 4, 4) Directive 2 at offset 4: "", length = 1 Substituting 4 for return value. /home/buildbot/repos/CMake/Source/cmLocalUnixMakefileGenerator3.cxx:1282: snprintf: objsize = 5, fmtstr = "%04d" Directive 1 at offset 0: "%04d" Result: 4, 4, 4, 4 (4, 4, 4, 4) Directive 2 at offset 4: "", length = 1 Substituting 4 for return value. If you see the warning with the latest GCC 12 please provide the full command line (see https://gcc.gnu.org/bugs/#need for a detailed list of what we ask users to provide in order to reproduce issues).
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006
--- Comment #21 from Jakub Jelinek ---
That is make -j48 from where?
Toplevel, or the libgfortran build dir, or toplevel make -j48
all-target-libgfortran or make -j48 maybe-all-target-libgfortran?
>From what I can see, toplevel all-target-libgfortran should do make all in the
libgfortran build dir:
ARGET-target-libgfortran=all
maybe-all-target-libgfortran: all-target-libgfortran
all-target-libgfortran: configure-target-libgfortran
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
$(NORMAL_TARGET_EXPORTS) \
(cd $(TARGET_SUBDIR)/libgfortran && \
$(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_TARGET_FLAGS) \
$(TARGET-target-libgfortran))
and all: in the libgfortran Makefile should be:
all: $(BUILT_SOURCES) config.h
$(MAKE) $(AM_MAKEFLAGS) all-am
(in your case with the ls -l added above it).
Perhaps also above the ls do
echo all in libgfortran, BUILT_SOURCES is $(BUILT_SOUCES)
What version of GNU make are you using?
I just don't understand how it could start building the object files etc.
which is done from all-am before actually ensuring all those $(BUILT_SOURCES)
like kinds.h exist.
[Bug fortran/102332] ICE in select_type_set_tmp, at fortran/match.c:6366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102332 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |10.4 --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch. Closing. Thanks for the report!
[Bug fortran/102332] ICE in select_type_set_tmp, at fortran/match.c:6366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102332 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7bfdbb657919b5049e459e02d130056cfe3777b6 commit r10-10393-g7bfdbb657919b5049e459e02d130056cfe3777b6 Author: Harald Anlauf Date: Mon Dec 27 23:06:18 2021 +0100 Fortran: avoid several NULL pointer dereferences during error recovery gcc/fortran/ChangeLog: PR fortran/102332 * expr.c (gfc_get_variable_expr): Avoid NULL pointer dereferences during handling of errors with invalid uses of CLASS variables. * match.c (select_type_set_tmp): Likewise. * primary.c (gfc_match_varspec): Likewise. * resolve.c (resolve_variable): Likewise. (resolve_select_type): Likewise. gcc/testsuite/ChangeLog: PR fortran/102332 * gfortran.dg/pr102332.f90: New test. (cherry picked from commit d8f6c48ccb85ecc0d97a84c32b7a1b8f43c64fe4)
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 --- Comment #20 from Rainer Orth --- Created attachment 52183 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52183&action=edit i386-pc-solaris2.11 libgfortran make -j48 output
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #18 from Jakub Jelinek --- > Some of the patches before #c13 were just buggy and could cause such errors. > Do you see the above on vanilla trunk? I do. > Can you perhaps patch your Makefile like: > all: $(BUILT_SOURCES) config.h > +ls -l config.h kinds.h fpu-target.h *.inc > $(MAKE) $(AM_MAKEFLAGS) all-am > and then > make -j64 all > LOG 2>&1 > ? That ls -l and its output don't even occur in the log (both when run manually and within a regular bootstrap): tons of sources are compiled before that point, and some of them fail.
[Bug tree-optimization/83072] Late VRP optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83072 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug modula2/101389] Parallel build doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101389 --- Comment #3 from Gaius Mulley --- I've pushed some changes to gcc/m2/Makefile.in on Tue Jan 11 19:21:06 2022 + which fix parallel build errors on stage1 binaries (exposed when -j48 was used). I've rebuilt gm2 using -j48 and -j64 and all regression test pass on x86_64 debian gnu/linux. Curious to know if it still fails on ASCII.lo on Solaris 11.
[Bug c++/70417] Unhelpful diagnostic for dependent template-name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70417 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b8ffa71e4271ae562c2d315b9b24c4979bbf8227 commit r12-6563-gb8ffa71e4271ae562c2d315b9b24c4979bbf8227 Author: Anthony Sharp Date: Sat Dec 4 17:23:22 2021 + c++: warning for dependent template members [PR70417] Add a helpful warning message for when the user forgets to include the "template" keyword after ., -> or :: when accessing a member in a dependent context, where the member is a template. PR c++/70417 gcc/c-family/ChangeLog: * c.opt: Added -Wmissing-template-keyword. gcc/cp/ChangeLog: * parser.c (cp_parser_id_expression): Handle -Wmissing-template-keyword. (struct saved_token_sentinel): Add modes to control what happens on destruction. (cp_parser_statement): Adjust. (cp_parser_skip_entire_template_parameter_list): New function that skips an entire template parameter list. (cp_parser_require_end_of_template_parameter_list): Rename old cp_parser_skip_to_end_of_template_parameter_list. (cp_parser_skip_to_end_of_template_parameter_list): Refactor to be called from one of the above two functions. (cp_parser_lambda_declarator_opt) (cp_parser_explicit_template_declaration) (cp_parser_enclosed_template_argument_list): Adjust. gcc/ChangeLog: * doc/invoke.texi: Documentation for Wmissing-template-keyword. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/variadic-mem_fn2.C: Catch warning about missing template keyword. * g++.dg/template/dependent-name17.C: New test. * g++.dg/template/dependent-name18.C: New test. Co-authored-by: Jason Merrill
[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101715
--- Comment #16 from Marek Polacek ---
This slightly modified test started to ICE with r11-4682 which is the gist of
the problem:
template struct S {
S bar() noexcept(T::value);
S foo() noexcept(T::value);
};
template S S::foo() noexcept(T::value) {}
[Bug fortran/103782] [9/10/11/12 Regression] internal error occurs when overloading intrinsic since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103782 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-January/057387.html
[Bug rtl-optimization/68212] Loop unroller breaks basic block frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68212 --- Comment #7 from Peter Bergner --- (In reply to Pat Haugen from comment #4) > Author: pthaugen > Date: Fri Oct 14 17:10:18 2016 > New Revision: 241170 > > URL: https://gcc.gnu.org/viewcvs?rev=241170&root=gcc&view=rev > Log: > PR rtl-optimization/68212 > * cfgloopmanip.c (duplicate_loop_to_header_edge): Use preheader edge > frequency when computing scale factor for peeled copies. > * loop-unroll.c (unroll_loop_runtime_iterations): Fix freq/count > values for switch/peel blocks/edges. Repeating Martin's question. Pat, is this PR fixed with your patch or is there more to do?
[Bug c++/104016] constexpr folding of std::type_info depends on -fdelete-null-ptr-checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104016
--- Comment #2 from Jakub Jelinek ---
I bet it is
/* If both symbols may resolve to NULL, we cannot really prove them
different. */
if (!memory_accessed && !nonzero_address () && !s2->nonzero_address ())
return -1;
which is done before:
/* If the FE tells us at least one of the decls will never be aliased nor
overlapping with other vars in some other way, return 0. */
if (VAR_P (decl)
&& (lookup_attribute ("non overlapping", DECL_ATTRIBUTES (decl))
|| lookup_attribute ("non overlapping", DECL_ATTRIBUTES (s2->decl
return 0;
Currently "non overlapping" attribute is used solely for typeinfo and we know
it doesn't have aliases etc., so for typeinfo we could fix that by moving the
"non overlapping" check above the above one.
But for the folding_initializer case we have later we should do something
different.
For addresses of extern weak vars surely they both can resolve to NULL and the
above makes a lot of sense, but for e.g. two vars defined somewhere they still
shouldn't overlap even if one of them could be at address zero.
[Bug c++/104016] constexpr folding of std::type_info depends on -fdelete-null-ptr-checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104016 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-01-13 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- N.B. when this is fixed we should remove -fdelete-null-pointer-checks from testsuite/18_support/type_info/constexpr.cc
[Bug c++/104016] New: constexpr folding of std::type_info depends on -fdelete-null-ptr-checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104016
Bug ID: 104016
Summary: constexpr folding of std::type_info depends on
-fdelete-null-ptr-checks
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
// { dg-options "-std=gnu++23 -fno-delete-null-pointer-checks" }
// { dg-do compile { target c++23 } }
#include
static_assert( typeid(int) != typeid(long) );
This compiles with the default flags, but -fno-delete-null-pointer-checks
causes it to fail:
ti.C:4:28: error: non-constant condition for static assertion
4 | static_assert( typeid(int) != typeid(long) );
|^~~
In file included from ti.C:3:
/home/jwakely/gcc/12/include/c++/12.0.0/typeinfo:196:19: error: '(((const
std::type_info*)(& _ZTIi)) == ((const std::type_info*)(& _ZTIl)))' is not a
constant expression
196 | return this == &__arg;
| ~^
Not a regression, because this code was rejected as ill-formed until very
recently.
Maybe related to PR c++/97913
[Bug c++/104013] Constructor for std::vector with single element initializer list defaults to length construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104013 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=83264 --- Comment #8 from Andrew Pinski --- See PR 83264 also.
[Bug c++/104013] Constructor for std::vector with single element initializer list defaults to length construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104013 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-01-13 Status|UNCONFIRMED |WAITING --- Comment #7 from Jonathan Wakely --- Please provide a proper testcase, that either fails to compile or fails at runtime. See https://gcc.gnu.org/bugs/
[Bug tree-optimization/104012] [12 regression] -Wformat-truncation warnings not taking previous length check into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012 --- Comment #2 from Rolf Eike Beer --- Created attachment 52182 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52182&action=edit preprocessed source
[Bug target/103861] [i386] vectorize v2qi vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103861 --- Comment #13 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:7a7d8c3f6167fd45658ddbfa32adcfd2acc98eb4 commit r12-6562-g7a7d8c3f6167fd45658ddbfa32adcfd2acc98eb4 Author: Uros Bizjak Date: Thu Jan 13 20:48:18 2022 +0100 i386: Introduce V2QImode vectorized shifts [PR103861] Add V2QImode shift operations and split them to synthesized double HI/LO QImode operations with integer registers. Also robustify arithmetic split patterns. 2022-01-13 Uroš Bizjak gcc/ChangeLog: PR target/103861 * config/i386/i386.md (*ashlqi_ext_2): New insn pattern. (*qi_ext_2): Ditto. * config/i386/mmx.md (v2qi): New insn_and_split pattern. gcc/testsuite/ChangeLog: PR target/103861 * gcc.target/i386/pr103861.c (shl,ashr,lshr): New tests.
[Bug target/104015] New: [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015 Bug ID: 104015 Summary: [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:016bd7523131b645bca5b5530c81ab5149922743, r12-6523 make -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/slp-perm-9.c" FAIL: gcc.dg/vect/slp-perm-9.c scan-tree-dump-times vect "permutation requires at least three vectors" 1 FAIL: gcc.dg/vect/slp-perm-9.c -flto -ffat-lto-objects scan-tree-dump-times vect "permutation requires at least three vectors" 1 # of expected passes8 # of unexpected failures2 This only fails on power 9. This worked as of g:828474fafd2ed33430172fe227f9da7d6fb98723, r12-6419. At r12-6420 the build was broken for powerpc64 until r12-6523 when I noticed this.
[Bug target/104014] [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104014 --- Comment #7 from Jakub Jelinek --- (In reply to David Binderman from comment #6) > (In reply to Jakub Jelinek from comment #5) > > That makes no sense. > > Surprising. > > bootstrap-O3 tests more of the compiler than the ordinary bootstrap-O2 does. Not really. It tests different code paths in the compiler. > > And, -march=native is a moving target, different for each developer. > > Indeed it is. We all have different boxes. But adding -march=native > tests more of the compiler. Not really. > Agreed. But if a native bootstrap works for some machine, > we can be pretty sure it will work for all predecessor machines > of the same architecture. Certainly not. > > > --with-arch=native --with-cpu=native bootstraps aren't a good idea for > > gcc-testresults posts as well because it is hard to determine what exactly > > that native expands to. > > It wouldn't be impossible to require folks to specify what their native > target was. >From my experience, that is a total nightmare. People usually say in such case if they specify anything I'm using a Skylake or something similar, in better cases Intel i9-7680X or whatever they have. But mapping that to the actual -march= -misa1 -misa2 etc. options that the -march=native expands to is hard, one needs to look up what model/stepping such CPU has somewhere and exact set of ISAs it supports and then try to repeat what driver-*.c does manually. Sure, one can use gcc -v and paste the cc1 etc. invocation line, but people just don't do that, so it is another step where you need to ask them. So it is much better if people actually test --with-arch=skylake-avx512 or whatever exact -march= they have, that isn't a moving target.
[Bug target/104014] [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104014 --- Comment #6 from David Binderman --- (In reply to Jakub Jelinek from comment #5) > That makes no sense. Surprising. bootstrap-O3 tests more of the compiler than the ordinary bootstrap-O2 does. That has to be a good thing for any candidate patch. > And, -march=native is a moving target, different for each developer. Indeed it is. We all have different boxes. But adding -march=native tests more of the compiler. > So bootstrap that works for one developer with -march=native can work fine > while on another box it will not. Agreed. But if a native bootstrap works for some machine, we can be pretty sure it will work for all predecessor machines of the same architecture. > --with-arch=native --with-cpu=native bootstraps aren't a good idea for > gcc-testresults posts as well because it is hard to determine what exactly > that native expands to. It wouldn't be impossible to require folks to specify what their native target was.
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Bug 85316 depends on bug 97909, which changed state. Bug 97909 Summary: expr_not_equal_to (mainly in match.pd) vs. ranger https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97909 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/97909] expr_not_equal_to (mainly in match.pd) vs. ranger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97909 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Andrew Macleod --- This support is now available.
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Bug 85316 depends on bug 83073, which changed state. Bug 83073 Summary: Range for VR_VARYING | [1, 1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83073 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/83073] Range for VR_VARYING | [1, 1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83073 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Andrew Macleod --- Ranger VRP also does match and simplify now for both EVRP and VRP2.
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Bug 85316 depends on bug 83072, which changed state. Bug 83072 Summary: Late VRP optimization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83072 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/83072] Late VRP optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83072 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Andrew Macleod --- Fixed. Just needed to enable multi-ranges in fold_const.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96707, which changed state. Bug 96707 Summary: Failure to optimize right shift+unsigned compare of two variables optimally https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96707 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/96707] Failure to optimize right shift+unsigned compare of two variables optimally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96707 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Macleod --- fixed.
[Bug tree-optimization/97909] expr_not_equal_to (mainly in match.pd) vs. ranger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97909 --- Comment #5 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:49d5fb4feee831868d80fff4d024c271911c92ca commit r12-6559-g49d5fb4feee831868d80fff4d024c271911c92ca Author: Andrew MacLeod Date: Wed Jan 12 13:31:08 2022 -0500 Allow more precision when querying from fold_const. fold_const::expr_not_equal_to queries for a current range, but still uses the old value_range class. This is causing it to miss opportunities when ranger can provide something better. PR tree-optimization/83072 PR tree-optimization/83073 PR tree-optimization/97909 gcc/ * fold-const.c (expr_not_equal_to): Use a multi-range class. gcc/testsuite/ * gcc.dg/pr83072-2.c: New. * gcc.dg/pr83073.c: New.
[Bug tree-optimization/83072] Late VRP optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83072 --- Comment #9 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:49d5fb4feee831868d80fff4d024c271911c92ca commit r12-6559-g49d5fb4feee831868d80fff4d024c271911c92ca Author: Andrew MacLeod Date: Wed Jan 12 13:31:08 2022 -0500 Allow more precision when querying from fold_const. fold_const::expr_not_equal_to queries for a current range, but still uses the old value_range class. This is causing it to miss opportunities when ranger can provide something better. PR tree-optimization/83072 PR tree-optimization/83073 PR tree-optimization/97909 gcc/ * fold-const.c (expr_not_equal_to): Use a multi-range class. gcc/testsuite/ * gcc.dg/pr83072-2.c: New. * gcc.dg/pr83073.c: New.
[Bug tree-optimization/83073] Range for VR_VARYING | [1, 1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83073 --- Comment #6 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:49d5fb4feee831868d80fff4d024c271911c92ca commit r12-6559-g49d5fb4feee831868d80fff4d024c271911c92ca Author: Andrew MacLeod Date: Wed Jan 12 13:31:08 2022 -0500 Allow more precision when querying from fold_const. fold_const::expr_not_equal_to queries for a current range, but still uses the old value_range class. This is causing it to miss opportunities when ranger can provide something better. PR tree-optimization/83072 PR tree-optimization/83073 PR tree-optimization/97909 gcc/ * fold-const.c (expr_not_equal_to): Use a multi-range class. gcc/testsuite/ * gcc.dg/pr83072-2.c: New. * gcc.dg/pr83073.c: New.
[Bug tree-optimization/96707] Failure to optimize right shift+unsigned compare of two variables optimally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96707 --- Comment #5 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:27e4260166950b784fe270ba4f0cae9a66faf1c4 commit r12-6558-g27e4260166950b784fe270ba4f0cae9a66faf1c4 Author: Andrew MacLeod Date: Wed Jan 12 13:28:55 2022 -0500 Add relation to unsigned right shift. If the first operand and the shift value of a right shift operation are both >= 0, then we know the LHS of the operation is <= the first operand. PR tree-optimization/96707 gcc/ * range-op.cc (operator_rshift::lhs_op1_relation): New. gcc/testsuite/ * g++.dg/pr96707.C: New.
[Bug target/104014] [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104014 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- That makes no sense. O2-ish bootstrap are the most commonly used ones, not O3-ish, so mandating bootstrap-O3 for testing is wrong. And, -march=native is a moving target, different for each developer. So bootstrap that works for one developer with -march=native can work fine while on another box it will not. --with-arch=native --with-cpu=native bootstraps aren't a good idea for gcc-testresults posts as well because it is hard to determine what exactly that native expands to.
[Bug target/104014] [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104014 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from David Binderman --- (In reply to H.J. Lu from comment #0) > On x86-64, r12-6538 breaks bootstrap with --with-arch=native Perhaps it is time to introduce some additional requirements for candidate patches. Anything that breaks bootstrap prevents other developers making progress. I would have thought that bootstrap-O3 would be a minimal requirement for any patch. The protocol is published at: https://gcc.gnu.org/contribute.html#testing In practice I use this: CC="clang -Wall" CXX="clang++ -Wall" \ ../trunk.git/configure --prefix=/home/dcb/gcc/$PREFIX \ --disable-multilib \ --disable-werror \ --with-pkgversion=$HASH \ --enable-checking=df,extra,fold,rtl,yes \ --enable-languages=c,c++,fortran sed 's/-O2/-O3 -march=native/' < Makefile > Makefile.tmp diff Makefile Makefile.tmp mv Makefile.tmp Makefile This works well for me.
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 --- Comment #18 from Jakub Jelinek --- Some of the patches before #c13 were just buggy and could cause such errors. Do you see the above on vanilla trunk? Can you perhaps patch your Makefile like: all: $(BUILT_SOURCES) config.h +ls -l config.h kinds.h fpu-target.h *.inc $(MAKE) $(AM_MAKEFLAGS) all-am and then make -j64 all > LOG 2>&1 ?
[Bug rtl-optimization/68212] Loop unroller breaks basic block frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68212 Bill Schmidt changed: What|Removed |Added Assignee|kelvin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #6 from Bill Schmidt --- Kelvin has moved on...
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 --- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #16 from Jakub Jelinek --- > The version file is now fixed. Thanks. > Can you perhaps rm -rf the libgfortran build directories and retry, if it > wasn't some weird BUILT_SOURCES problem caused by it failing early because of > the gfortran version file failure? Have you ever seen such failures before? I believe I've tried that before and now did again with just the version file fix: no dice. And no, this is the first time ever that I had such an issue. > As documented in automake, BUILT_SOURCES is only for all, check and install > goals, if one does make fpu.lo it will not work. After the fresh built, among others with /vol/gcc/src/hg/master/local/libgfortran/ieee/ieee_exceptions.F90:28:2: 28 | #include "c99_protos.inc" | 1~~ Fatal Error: kinds.inc: No such file or directory I compared make --debug=verbose for that file and bounds.lo: one glaring difference is that for bounds.lo the debug output lists Considering target file 'bounds.lo'. File 'bounds.lo' does not exist. Considering target file '/vol/gcc/src/hg/master/local/libgfortran/runtime/bounds.c'. Finished prerequisites of target file '/vol/gcc/src/hg/master/local/libgfortran/runtime/bounds.c'. No need to remake target '/vol/gcc/src/hg/master/local/libgfortran/runtime/bounds.c'. Pruning file '/vol/gcc/src/hg/master/local/libgfortran/runtime/bounds.c'. Considering target file '/vol/gcc/src/hg/master/local/libgfortran/libgfortran.h'. Finished prerequisites of target file '/vol/gcc/src/hg/master/local/libgfortran/libgfortran.h'. [...] while ieee_exceptions.lo has only Considering target file 'ieee_exceptions.lo'. File 'ieee_exceptions.lo' does not exist. Considering target file 'ieee/ieee_exceptions.F90'. Finished prerequisites of target file 'ieee/ieee_exceptions.F90'. No need to remake target 'ieee/ieee_exceptions.F90'; using VPATH name '/vol/gcc/src/hg/master/local/libgfortran/ieee/ieee_exceptions.F90'. Finished prerequisites of target file 'ieee_exceptions.lo'. Must remake target 'ieee_exceptions.lo'. i.e. it lists no prerequisites beside the source itself. The bounds.lo prerequisites are both from the Makefile proper and .deps/bounds.Plo while .deps/ieee_exceptions.Plo doesn't exist/isn't generated. The compile command for bounds.lo includes -MF $(DEPDIR)/bounds.Tpo has nothing of the kind. No idea why. Maybe a difference between C and Fortran sources in Automake?
[Bug fortran/67804] ICE on data initialization of type(character) with wrong data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 --- Comment #5 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:0b8464365b15ac108cd1d00d5bc56d229c1340de commit r12-6557-g0b8464365b15ac108cd1d00d5bc56d229c1340de Author: Harald Anlauf Date: Wed Jan 12 21:24:49 2022 +0100 Fortran: fix error recovery on bad structure constructor in DATA statement gcc/fortran/ChangeLog: PR fortran/67804 * primary.c (gfc_match_structure_constructor): Recover from errors that occurred while checking for a valid structure constructor in a DATA statement. gcc/testsuite/ChangeLog: PR fortran/67804 * gfortran.dg/pr93604.f90: Adjust to changed diagnostics. * gfortran.dg/pr67804.f90: New test.
[Bug target/104014] [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104014 Martin Liška changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Martin Liška --- Then please provide a test-case and options.
[Bug target/104014] [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104014 --- Comment #2 from H.J. Lu --- (In reply to Martin Liška from comment #1) > Is it the same as PR104001? Maybe. I don't know if the fix is complete.
[Bug target/104014] [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104014 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Is it the same as PR104001?
[Bug target/104014] [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104014 H.J. Lu changed: What|Removed |Added Last reconfirmed||2022-01-13 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug target/104014] [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104014 H.J. Lu changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/104014] New: [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104014 Bug ID: 104014 Summary: [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: haochen.jiang at intel dot com Reporter: hjl.tools at gmail dot com CC: crazylht at gmail dot com, haochen.jiang at intel dot com Target Milestone: --- Target: x86-64 On x86-64, r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native: ../../src-master/libdecnumber/decContext.c: In function ??decContextRestoreStatus??: ../../src-master/libdecnumber/decContext.c:183:3: error: unrecognizable insn: 183 | } /* decContextRestoreStatus */ | ^ (insn 25 24 17 2 (parallel [ (set (mem:SI (plus:DI (reg/v/f:DI 87 [ context ]) (const_int 20 [0x14])) [1 context_7(D)->status+0 S4 A32]) (ior:SI (reg:SI 97) (reg:SI 98))) (clobber (reg:CC 17 flags)) ]) "../../src-master/libdecnumber/decContext.c":181:18 -1 (expr_list:REG_DEAD (reg:SI 98) (expr_list:REG_DEAD (reg:SI 97) (expr_list:REG_UNUSED (reg:CC 17 flags) (nil) during RTL pass: ira
[Bug c++/104008] [11/12 Regression] New g++ folly compile error with gcc 11.x. Bisected to PR99445 c++: Alias template in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 Jonathan Wakely changed: What|Removed |Added Known to work||10.3.0 Keywords||rejects-valid See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102869 --- Comment #1 from Jonathan Wakely --- Possible dup of PR 102869
[Bug c++/99445] [11 Regression] ICE in hashtab_chk_error, at hash-table.c:137 since r11-7011-g6e0a231a4aa2407b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99445 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104008 --- Comment #11 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #10) > There's a report of a regression caused by this: > https://gcc.gnu.org/pipermail/gcc-help/2022-January/141127.html > I'll ask for it to be reported to bugzilla. That's now PR 104008
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 --- Comment #16 from Jakub Jelinek --- The version file is now fixed. Can you perhaps rm -rf the libgfortran build directories and retry, if it wasn't some weird BUILT_SOURCES problem caused by it failing early because of the gfortran version file failure? Have you ever seen such failures before? As documented in automake, BUILT_SOURCES is only for all, check and install goals, if one does make fpu.lo it will not work.
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 --- Comment #15 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:70ba28304b7ff91761db248bc8354eda8e9a4796 commit r12-6555-g70ba28304b7ff91761db248bc8354eda8e9a4796 Author: Jakub Jelinek Date: Thu Jan 13 17:45:58 2022 +0100 libgfortran: Fix Solaris version file creation [PR104006] I forgot to change the gfortran.map-sun goal to gfortran.ver-sun when changing other spots for the preprocessed version file. 2022-01-13 Jakub Jelinek PR libfortran/104006 * Makefile.am (gfortran.map-sun): Rename target to ... (gfortran.ver-sun): ... this. * Makefile.in: Regenerated.
[Bug c++/104013] Constructor for std::vector with single element initializer list defaults to length construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104013
--- Comment #6 from Alexander Poeppel ---
It works as expected when wrapping the int in double braces:
std::vector vec_test_any = std::vector({{5}});
[Bug c++/104013] Constructor for std::vector with single element initializer list defaults to length construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104013
--- Comment #5 from Alexander Poeppel ---
(In reply to Andrew Pinski from comment #3)
> DR 2137 is the one. No other compiler implements it.
That seems to be a different issue, since it pertains to copy cosntruction vs.
initializer list construction.
This issue concerns the incorrect overload resolution between
template
std::vector(size_t n) {...}
and
template
std::vector(std::initializer_list l) {...}
for T = std::any. It works for T = int. So I think it might be a problem in the
implementation of std::any, since it only goes wrong for that type.
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 --- Comment #14 from Jakub Jelinek --- Anyway, let me commit the gfortran.ver-sun fix as obvious separately.
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 Jakub Jelinek changed: What|Removed |Added Attachment #52180|0 |1 is obsolete|| --- Comment #13 from Jakub Jelinek --- Created attachment 52181 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52181&action=edit gcc12-pr104006.patch Updated patch that should cure it. But reading the automake manual and the generated Makefile, I actually don't understand why you are getting any problems (except the gfortran.ver-sun). All these generated *.inc and *.h files are mentioned in BUILT_SOURCES, and e.g. the all: rule looks like: all: $(BUILT_SOURCES) config.h $(MAKE) $(AM_MAKEFLAGS) all-am so make all (and other goes like make check) should make sure all these *.inc and *.h generated files appear before running recursive make to build everything.
[Bug c++/104013] Constructor for std::vector with single element initializer list defaults to length construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104013 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > DR 2137 is the one. No other compiler implements it. Note this is defect report against the c++ standard. There are others which related to the single initializer_list going to scalar too.
[Bug c++/104013] Constructor for std::vector with single element initializer list defaults to length construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104013 --- Comment #3 from Andrew Pinski --- DR 2137 is the one. No other compiler implements it.
[Bug c++/104013] Constructor for std::vector with single element initializer list defaults to length construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104013 --- Comment #2 from Alexander Poeppel --- (In reply to Andrew Pinski from comment #1) > I think there is defect report about this specific thing. I couldn't find a corresponding report, and the suggestions when posting this didn't turn anything similar up either. If you can find it, then please post a link and this report can be closed.
[Bug target/95737] PPC: Unnecessary extsw after negative less than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737 --- Comment #8 from Segher Boessenkool --- Somewhat more constructive... The problem here is that neg isn't pushed "through" isel insns. This in general means you need to negate both inputs to the isel of course, but there are cases where that is advantageous, like here when both of those inputs are constants (or actually registers, but set to some constant). This is one reason the new set[n]bc[r] insns are so useful to us: it is all one insn, also on RTL level, so it naturally works out in such cases. It also is slightly faster anyway of course, fewer insns and all that, even if for dataflow it is all the same.
[Bug c++/104013] Constructor for std::vector with single element initializer list defaults to length construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104013 Andrew Pinski changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #1 from Andrew Pinski --- I think there is defect report about this specific thing.
[Bug libstdc++/104013] New: Constructor for std::vector with single element initializer list defaults to length construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104013
Bug ID: 104013
Summary: Constructor for std::vector with single
element initializer list defaults to length
construction
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: trekie10b at gmx dot de
Target Milestone: ---
std: c++17
The following code initializes a vector of int with one element (5):
std::vector vec_test_int = std::vector({5});
The following code, however initializes the vector with 5 empty std::any
objects:
std::vector vec_test_any = std::vector({5});
As per the standard (§13.3.1.7), the initializer_list constructor overload of T
(std::any) should take precedence over that of std::vector, as it does in the
first case.
[Bug target/104003] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-6488-g820ac79e8448ad6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104003 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Uroš Bizjak --- Fixed.
[Bug target/104003] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-6488-g820ac79e8448ad6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104003 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:9d8e27fac3c6426fbfaf30d51cbf2761c5491a6a commit r12-6554-g9d8e27fac3c6426fbfaf30d51cbf2761c5491a6a Author: Uros Bizjak Date: Thu Jan 13 17:18:59 2022 +0100 ii386: Add 16-bit vector modes to xop_pcmov [PR104003] 2022-01-13 Uroš Bizjak gcc/ChangeLog: PR target/104003 * config/i386/mmx.md (*xop_pcmov_): Use VI_16_32 mode iterator. gcc/testsuite/ChangeLog: PR target/104003 * g++.target/i386/pr103861-1-sse4.C: New test. * g++.target/i386/pr103861-1-xop.C: Ditto.
[Bug target/104001] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-6538-g5f19303ada7db92c155332e7ba317233ca05946b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104001
--- Comment #4 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #2)
> I'm testing
>
> 1 file changed, 3 insertions(+), 3 deletions(-)
> gcc/config/i386/i386.md | 6 +++---
>
> modified gcc/config/i386/i386.md
> @@ -10455,7 +10455,7 @@ (define_insn_and_split "*xordi_1_btc"
>
> ;; PR target/94790: Optimize a ^ ((a ^ b) & mask) to (~mask & a) | (b &
> mask)
Please remove the reference to the PR.
> (define_insn_and_split "*xor2andn"
> - [(set (match_operand:SWI248 0 "nonimmediate_operand")
> + [(set (match_operand:SWI248 0 "register_operand")
> (xor:SWI248
> (and:SWI248
> (xor:SWI248
> @@ -10464,8 +10464,7 @@ (define_insn_and_split "*xor2andn"
> (match_operand:SWI248 3 "nonimmediate_operand"))
> (match_dup 1)))
> (clobber (reg:CC FLAGS_REG))]
> - "(TARGET_BMI || TARGET_AVX512BW)
> - && ix86_pre_reload_split ()"
> + "TARGET_BMI && ix86_pre_reload_split ()"
>"#"
>"&& 1"
>[(parallel [(set (match_dup 4)
> @@ -10486,6 +10485,7 @@ (define_insn_and_split "*xor2andn"
> (clobber (reg:CC FLAGS_REG))])]
> {
>operands[1] = force_reg (mode, operands[1]);
> + operands[2] = force_reg (mode, operands[2]);
You don't need to force this operand to reg, "and" will accept memory operand.
But please swap (match_dup 2) and (match_dup 3) here:
+ (parallel [(set (match_dup 5)
+ (and:SWI248
+ (match_dup 2)
+ (match_dup 3)))
+ (clobber (reg:CC FLAGS_REG))])
This will ease RA job a bit.
The patch is pre-approved with the above changes.
>operands[3] = force_reg (mode, operands[3]);
>operands[4] = gen_reg_rtx (mode);
>operands[5] = gen_reg_rtx (mode);
>
> [back]
[Bug tree-optimization/104012] [12 regression] -Wformat-truncation warnings not taking previous length check into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012 Andrew Pinski changed: What|Removed |Added Component|c++ |tree-optimization Target Milestone|--- |12.0 Keywords||diagnostic Summary|-Wformat-truncation |[12 regression] |warnings not taking |-Wformat-truncation |previous length check into |warnings not taking |account |previous length check into ||account --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source?
[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243 Segher Boessenkool changed: What|Removed |Added Status|NEW |WAITING CC||segher at gcc dot gnu.org --- Comment #2 from Segher Boessenkool --- Do you have a testcase?
[Bug c++/104012] New: -Wformat-truncation warnings not taking previous length check into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012
Bug ID: 104012
Summary: -Wformat-truncation warnings not taking previous
length check into account
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@sf-mail.de
Target Milestone: ---
This code is from CMake's Source/cmLocalUnixMakefileGenerator3.cxx:
std::string cmLocalUnixMakefileGenerator3::CreateMakeVariable(
std::string const& s, std::string const& s2)
{
[…]
char buffer[5];
int ni = 0;
snprintf(buffer, sizeof(buffer), "%04d", ni);
ret = str1 + str2 + buffer;
while (this->ShortMakeVariableMap.count(ret) && ni < 1000) {
++ni;
snprintf(buffer, sizeof(buffer), "%04d", ni);
ret = str1 + str2 + buffer;
}
The second snprintf() causes this warning:
…/CMake/Source/cmLocalUnixMakefileGenerator3.cxx:1311:41: warning: '%04d'
directive output may be truncated writing between 4 and 11 bytes into a region
of size 5 [-Wformat-truncation=]
1311 | snprintf(buffer, sizeof(buffer), "%04d", ni);
| ^~~~
…/CMake/Source/cmLocalUnixMakefileGenerator3.cxx:1311:40: note: directive
argument in the range [-2147483647, 2147483647]
1311 | snprintf(buffer, sizeof(buffer), "%04d", ni);
|^~
The second warning line shows that the argument range is not correctly limited
to [0, 1000], which would have avoided the warning. A similar warning is shown
~30 lines earlier in the same file for basically the same code.
My current version is:
gcc-12.0.0 (Gentoo 12.0.0_pre p2, commit
8b35f02ed599a70cce752e3cb544a7c9f808fce8) 12.0.0 20220111 (experimental)
The version used previously has been built on 2021-08-14T20:47:39 and didn't
show that warning.
[Bug tree-optimization/104010] [12 regression] short loop no longer vectorized with Neon after r12-6513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010 --- Comment #2 from Christophe Lyon --- Ha right, git gcc-descr with no argument didn't what I expected (ie. git gcc-descr HEAD after a bisect...) So I meant r12-3362 g:a3fb781d4b341c0d50ef1b92cd3e8734e673ef18
[Bug c/104011] New: s390: r12 is not setup for _mcount call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104011
Bug ID: 104011
Summary: s390: r12 is not setup for _mcount call
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stli at linux dot ibm.com
Target Milestone: ---
On 31bit, as r12 is not setup before brasl _mcount@plt, we jump to a
different function.
Note that the PIE plt-slot is using r12.
In the debugging-case, e.g. __libc_calloc is called.
In a different glibc-testcase "gmon/tst-gmon-pie" we jump to another function,
which leads to a segfault.
This happens with, e.g.:
- gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)
- gcc 11.2.0
Steps to reproduce:
$ cat tst-pie-mcount.c
#include
#include
int
main (void)
{
puts ("Hello world");
return EXIT_SUCCESS;
}
$ gcc -o tst-pie-mcount -g -m31 -fpie -pg -pie tst-pie-mcount.c
$ objdump -d tst-pie-mcount
...
05c8 <_mcount@plt>:
5c8: 58 10 c0 20 l %r1,32(%r12)
5cc: 07 f1 br %r1
5ce: 00 00 00 00 .long 0x
5d2: 00 00 0d 10 .long 0x0d10
5d6: 58 10 10 0e l %r1,14(%r1)
5da: a7 f4 ff 97 j 508 <.plt>
...
5e6: 00 3c .short 0x003c
...
0860 :
860: 50 e0 f0 04 st %r14,4(%r15)
864: c0 10 00 00 0b f2 larl%r1,2048 <__data_start+0x4>
We jump to the plt-slot, which uses r12, which is loaded later.
86a: c0 e5 ff ff fe af brasl %r14,5c8 <_mcount@plt>
870: 58 e0 f0 04 l %r14,4(%r15)
874: 90 bf f0 2c stm %r11,%r15,44(%r15)
878: a7 fa ff a0 ahi %r15,-96
87c: 18 bf lr %r11,%r15
GOT-Pointer is loaded here for puts:
87e: c0 c0 00 00 0b c1 larl%r12,2000 <_GLOBAL_OFFSET_TABLE_>
884: c0 20 00 00 00 6c larl%r2,95c <_IO_stdin_used+0x4>
88a: c0 e5 ff ff fe 7f brasl %r14,588
890: a7 18 00 00 lhi %r1,0
894: 18 21 lr %r2,%r1
896: 98 bf b0 8c lm %r11,%r15,140(%r11)
89a: 07 fe br %r14
89c: 07 07 nopr%r7
89e: 07 07 nopr%r7
*/
[Bug tree-optimization/104010] [12 regression] short loop no longer vectorized with Neon after r12-6513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010 --- Comment #1 from Andrew Pinski --- I think you have the wrong revision in there as that commit only adds a testcase.
[Bug tree-optimization/104010] New: [12 regression] short loop no longer vectorized with Neon after r12-6513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010
Bug ID: 104010
Summary: [12 regression] short loop no longer vectorized with
Neon after r12-6513
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
This short loop:
void test_vcmpeq_s32x2 (int32_t * __restrict__ dest, int32_t *a, int32_t *b)
{
int i;
for (i=0; i<4; i++) {
dest[i] = a[i] == b[i];
}
}
used to be vectorized as:
test_vcmpeq_s32x2:
vld1.32 {d16}, [r1]
vmov.i32d17, #0x1 @ v2si
vld1.32 {d19}, [r2]
vmov.i32d18, #0 @ v2si
vceq.i32d16, d16, d19
vbsld16, d17, d18
vst1.32 {d16}, [r0]
bx lr
After r12-6513, we get:
test_vcmpeq_s32x2:
ldr ip, [r1]
ldr r3, [r1, #4]
str lr, [sp, #-4]!
ldr lr, [r2]
ldr r2, [r2, #4]
sub ip, ip, lr
clz ip, ip
sub r3, r3, r2
lsr ip, ip, #5
clz r3, r3
lsr r3, r3, #5
str ip, [r0]
str r3, [r0, #4]
ldr pc, [sp], #4
when compiling for arm-none-linux-gnueabihf with -mcpu=cortex-a9 -mfpu=neon
[Bug tree-optimization/104009] [12 Regression] r12-6030-g422f9eb7011b76c1 breaks kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104009 Jakub Jelinek changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |12.0 CC||jakub at gcc dot gnu.org Summary|r12-6030-g422f9eb7011b76c1 |[12 Regression] |breaks kernel build |r12-6030-g422f9eb7011b76c1 ||breaks kernel build --- Comment #2 from Jakub Jelinek --- Well, it is a P1 just from being a regression from 11 on a primary or secondary platform (and even more so as it is wrong-code).
[Bug c++/103672] [10/11/12 Regression] using with template class> causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103672 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91911 --- Comment #2 from Patrick Palka --- Closely related to PR91911 due to the use of CTAD + alias template
[Bug tree-optimization/104009] r12-6030-g422f9eb7011b76c1 breaks kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104009 Siddhesh Poyarekar changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot gnu.org Priority|P3 |P1 CC||marxin at gcc dot gnu.org Last reconfirmed||2022-01-13 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Siddhesh Poyarekar --- Bumping to P1 since we want to be able to build the kernel with fortification.
[Bug tree-optimization/104009] New: r12-6030-g422f9eb7011b76c1 breaks kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104009
Bug ID: 104009
Summary: r12-6030-g422f9eb7011b76c1 breaks kernel build
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: siddhesh at gcc dot gnu.org
Target Milestone: ---
Reproducer gleaned from the kernel:
const char *
nlmdbg_cookie2a(unsigned n, char **data)
{
static char buf[255];
unsigned int i, len = sizeof(buf);
char *p = buf;
len--; /* allow for trailing \0 */
for (i = 0 ; i < n ; i++)
{
if (len < 2)
{
__builtin___strcpy_chk(p-3, "...", __builtin_object_size (p-3, 1));
break;
}
p += 2;
len -= 2;
}
*p = '\0';
return buf;
}
$ cat repr.c.031t.early_objsz
;; Function nlmdbg_cookie2a (nlmdbg_cookie2a, funcdef_no=0, decl_uid=1980,
cgraph_uid=1, symbol_order=0)
Computing maximum subobject size for _1:
Visiting use-def links for _1
Visiting use-def links for p_6
Visiting use-def links for p_9
Visiting use-def links for p_14
Found a dependency loop at p_6
Need to reexamine p_14
Need to reexamine p_6
Need to reexamine _1
Visiting use-def links for _1
Need to reexamine _1
Reexamining _1
Visiting use-def links for p_6
Need to reexamine p_6
Reexamining p_6
Visiting use-def links for p_14
Need to reexamine p_14
Reexamining p_14
_1: maximum subobject size 0
p_6: maximum subobject size 255
p_9: maximum subobject size 255
p_14: maximum subobject size 253
const char * nlmdbg_cookie2a (unsigned int n, char * * data)
{
char * p;
unsigned int len;
unsigned int i;
static char buf[255];
char * _1;
long unsigned int _2;
char * _3;
const char * _19;
long unsigned int _20;
:
len_8 = 255;
p_9 = &buf;
len_10 = len_8 + 4294967295;
i_11 = 0;
goto ; [INV]
:
if (len_5 <= 1)
goto ; [INV]
else
goto ; [INV]
:
_1 = p_6 + 18446744073709551613;
_20 = __builtin_object_size (_1, 1);
_2 = MIN_EXPR <_20, 0>;
_3 = p_6 + 18446744073709551613;
__builtin___memcpy_chk (_3, "...", 4, _2);
goto ; [INV]
:
p_14 = p_6 + 2;
len_15 = len_5 + 4294967294;
i_16 = i_4 + 1;
:
# i_4 = PHI
# len_5 = PHI
# p_6 = PHI
if (i_4 < n_12(D))
goto ; [INV]
else
goto ; [INV]
:
*p_6 = 0;
_19 = &buf;
return _19;
}
Basically since p_6 is an estimate (i.e. the wholesize) and not a precise
value, negative offsets don't quite work. I need to figure out a way to punt
on negative offsets if we're using size estimates instead of precise sizes.
This means that it'll work for dynamic object sizes (because at the moment
they're always precise expressions) but not always for static sizes.
Right now it breaks for dynamic object sizes too, but that's only because
early_objsz treats __builtin_dynamic_object_size as __builtin_object_size to
get an upper bound and ends up zeroing it. So punting should fix that too.
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #11 from Jakub Jelinek --- > That is weird. > We have: > ieee_arithmetic.lo: ieee/ieee_arithmetic.F90 ieee_exceptions.lo > dependency and ieee_exceptions.mod is created when compiling > ieee_exceptions.lo. Here's what I see: ieee_exceptions.mod is missing. $ make -n ieee_arithmetic.lo /bin/ksh ./libtool --tag=FC --mode=compile /var/gcc/regression/master/11.4-gcc/build/./gcc/gfortran -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include-DHAVE_CONFIG_H -I. -I/vol/gcc/src/hg/master/local/libgfortran -iquote/vol/gcc/src/hg/master/local/libgfortran/io -I/vol/gcc/src/hg/master/local/libgfortran/../gcc -I/vol/gcc/src/hg/master/local/libgfortran/../gcc/config -I/vol/gcc/src/hg/master/local/libgfortran/../libquadmath -I../.././gcc -I/vol/gcc/src/hg/master/local/libgfortran/../libgcc -I../libgcc -I/vol/gcc/src/hg/master/local/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace -I . -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring -Wno-unused-dummy-argument -Wno-c-binding-type -ffree-line-length-0 -fallow-leading-underscore -fsignaling-nans -fbuilding-libgfortran -g -O2 -c -o ieee_arithmetic.lo /vol/gcc/src/hg/master/local/libgfortran/ieee/ieee_arithmetic.F90 $ make -n ieee_exceptions.mod : $ make -n ieee_exceptions.lo make: Nothing to be done for 'ieee_exceptions.lo'. ieee_exceptions.lo doesn't exist either.
[Bug tree-optimization/103989] [12 regression] std::optional and bogus -Wmaybe-unitialized at -Og since r12-1992-g6feb628a706e86eb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103989 --- Comment #17 from rguenther at suse dot de --- On Thu, 13 Jan 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103989 > > --- Comment #16 from Jakub Jelinek --- > Perhaps if we punt for -Og caller (and maybe -Og callees) on IPA inlining > except for always_inline, we could set some flag if IPA inlining happened and > schedule some extra cleanup passes just for those rare cases? I'd rather not. At some point I wanted to refactor the main opt pipeline to work like this and skip some of the early passes there if we did _not_ inline ... > Though arguably, if a call to always_inline function was indirect during > einline, we don't need to guarantee that it will be inlined. > But, what about -Og -fno-early-inlining? -Og -fno-early-inline will still do always inline inlining early. /* Even when not optimizing or not inlining inline always-inline functions. */ inlined = inline_always_inline_functions (node);
