[Bug tree-optimization/109341] New: [13 Regression] ICE in merge, at ipa-modref-tree.cc:176
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109341
Bug ID: 109341
Summary: [13 Regression] ICE in merge, at
ipa-modref-tree.cc:176
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskiy at gmail dot com
Target Milestone: ---
Link to the Compiler Explorer: https://godbolt.org/z/9zY57K3Yh
GCC also warns about UB, but I think it is incorrect. The code is well-defined
if "h" is equal to "1".
Reproducer:
unsigned c;
int e, f;
void g(long h, long j[][9]) {
for (long d = 1; d; d += -(h ?: 60)) {
{
int a = j[d][d];
f = h ?: a;
}
int i = f;
{
int a = c, b = i;
e = b ?: a;
}
c = e;
}
}
Error:
>$ g++ -O3 -c func.cpp
func.cpp: In function 'void g(long int, long int (*)[9])':
func.cpp:6:18: warning: iteration 7 invokes undefined behavior
[-Waggressive-loop-optimizations]
6 | int a = j[d][d];
| ^
func.cpp:4:20: note: within this loop
4 | for (long d = 1; d; d += -(h ?: 60)) {
|^
during GIMPLE pass: modref
func.cpp:3:6: internal compiler error: in merge, at ipa-modref-tree.cc:176
3 | void g(long h, long j[][9]) {
| ^
0x84f1a9 modref_access_node::merge(modref_access_node const&, bool)
/testing/gcc/gcc_src_master/gcc/ipa-modref-tree.cc:176
0x10147cc modref_access_node::try_merge_with(vec*&, unsigned long)
/testing/gcc/gcc_src_master/gcc/ipa-modref-tree.cc:457
0x1016562 modref_access_node::insert(vec*&, modref_access_node, unsigned long, bool)
/testing/gcc/gcc_src_master/gcc/ipa-modref-tree.cc:562
0x101220b modref_ref_node::insert_access(modref_access_node, unsigned
long, bool)
/testing/gcc/gcc_src_master/gcc/ipa-modref-tree.h:194
0x101220b modref_tree::insert(unsigned int, unsigned int, unsigned int,
int, int, modref_access_node, bool)
/testing/gcc/gcc_src_master/gcc/ipa-modref-tree.h:444
0x1004eac modref_tree::insert(tree_node*, int, int, modref_access_node
const&, bool)
/testing/gcc/gcc_src_master/gcc/ipa-modref-tree.h:471
0x1004eac record_access
/testing/gcc/gcc_src_master/gcc/ipa-modref.cc:1076
0x1005958 analyze_load
/testing/gcc/gcc_src_master/gcc/ipa-modref.cc:1707
0xf57cb4 walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*,
tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*,
void*), bool (*)(gimple*, tree_node*, tree_node*, void*))
/testing/gcc/gcc_src_master/gcc/gimple-walk.cc:813
0x100ba01 analyze_stmt
/testing/gcc/gcc_src_master/gcc/ipa-modref.cc:1788
0x100d1e9 analyze
/testing/gcc/gcc_src_master/gcc/ipa-modref.cc:1900
0x100d1e9 analyze_function
/testing/gcc/gcc_src_master/gcc/ipa-modref.cc:3220
0x100ecae execute
/testing/gcc/gcc_src_master/gcc/ipa-modref.cc:4187
gcc version 13.0.1 20230329 (3be4e43a6a0f429648ea188c8e110b74268fed27)
[Bug tree-optimization/109342] New: [13 Regression] Wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342
Bug ID: 109342
Summary: [13 Regression] Wrong code with -O2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskiy at gmail dot com
Target Milestone: ---
Link to the Compiler Explorer: https://godbolt.org/z/zKqcna3vn
Reproducer:
#include
unsigned long long int var_4 = 42;
unsigned long long int var_14 = 10;
unsigned char var_16 = 1;
unsigned short var_18 = 0;
short var_75;
inline const int &foo(const int &b, const int &c) { return b < c ? c : b; }
inline unsigned long long &bar(unsigned long long &b, unsigned long long &c) {
return !c ? c : b;
}
void test(unsigned long long var_4, unsigned long long var_14,
unsigned char var_16, unsigned short var_18) __attribute__((noipa));
void test(unsigned long long var_4, unsigned long long var_14,
unsigned char var_16, unsigned short var_18) {
for (bool h = 0; h < (bool)foo(var_16 ? -7 : 4, var_4 ? var_4 : var_18);
h = 2)
var_75 = bar(var_4, var_14);
}
int main() {
test(var_4, var_14, var_16, var_18);
printf("%hd\n", var_75);
if (var_75 != 42)
__builtin_abort();
}
Error:
>$ g++ -O0 small.cpp && ./a.out
42
>$ g++ -O2 small.cpp && ./a.out
0
Aborted (core dumped)
gcc version 13.0.1 20230329 (3be4e43a6a0f429648ea188c8e110b74268fed27)
[Bug rtl-optimization/109343] New: invalid if conversion optimization for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109343
Bug ID: 109343
Summary: invalid if conversion optimization for aarch64
Product: gcc
Version: rust/master
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jiangning.liu at amperecomputing dot com
Target Milestone: ---
For this small case, if-conversion optimization in back-end generated csel
instruction for aarch64, which is unsafe. The address of variable sga_var could
be invalid if sga_mapped is false.
$ cat ttt2.c
extern int sga_mapped, sga_var;
int func(int j){
int i=0;
if(sga_mapped)
i=i+sga_var;
return i;
}
$ gcc -O3 -S ttt2.c
$ cat ttt2.s
.arch armv8-a
.file "ttt2.c"
.text
.align 2
.p2align 4,,11
.global func
.type func, %function
func:
.LFB0:
.cfi_startproc
adrpx0, sga_mapped
adrpx1, sga_var
ldr w0, [x0, #:lo12:sga_mapped]
ldr w1, [x1, #:lo12:sga_var]
cmp w0, 0
cselw0, w1, w0, ne
ret
.cfi_endproc
.LFE0:
.size func, .-func
.ident "GCC: (GNU) 12.2.1 20221121 (Red Hat 12.2.1-4)"
.section.note.GNU-stack,"",@progbits
For x86, the following code is generated. It is safe because the memory access
to sga_var(%rip) won't be really triggered if %eax is not set. Here x86 and
aarch64 are different.
$ cat ttt2.s
.file "ttt2.c"
.text
.p2align 4
.globl func
.type func, @function
func:
.LFB0:
.cfi_startproc
endbr64
movlsga_mapped(%rip), %eax
testl %eax, %eax
cmovne sga_var(%rip), %eax
ret
[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
--- Comment #6 from Jakub Jelinek ---
Ok. It is yours then, for testcase perhaps:
--- gcc/testsuite/gcc.dg/pr109303.c.jj 2023-03-29 18:42:31.068144102 +0200
+++ gcc/testsuite/gcc.dg/pr109303.c 2023-03-29 18:42:18.328330526 +0200
@@ -0,0 +1,24 @@
+/* PR ipa/109303 */
+/* { dg-do compile { target lp64 } } */
+/* { dg-options "-O2" } */
+
+struct __attribute__((packed)) A { char c1; short a1[__INT_MAX__]; };
+struct __attribute__((packed)) B { char c2; short a2[100]; };
+struct S { struct A p1; struct B p2[4]; };
+void bar (short int);
+
+static void
+foo (struct S *q)
+{
+ for (int i = 0; i < q->p1.c1; i++)
+for (int j = 0; j < q->p2[i].c2; j++)
+ bar (q->p2[i].a2[j]);
+}
+
+int
+main ()
+{
+ struct S q = {};
+ q.p2[0].c2 = q.p2[1].c2 = 3;
+ foo (&q);
+}
(without lp64 it obviously fails on 32-bit targets).
[Bug ipa/109341] [12/13 Regression] ICE in merge, at ipa-modref-tree.cc:176
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109341 Richard Biener changed: What|Removed |Added Known to work||11.3.1 Last reconfirmed||2023-03-30 Keywords||ice-checking, ||needs-bisection Component|tree-optimization |ipa Priority|P3 |P2 Ever confirmed|0 |1 Known to fail||12.2.1, 13.0 Status|UNCONFIRMED |NEW Summary|[13 Regression] ICE in |[12/13 Regression] ICE in |merge, at |merge, at |ipa-modref-tree.cc:176 |ipa-modref-tree.cc:176 CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org Target Milestone|--- |12.3 --- Comment #1 from Richard Biener --- Confirmed, also ICEs on the 12 branch.
[Bug tree-optimization/109342] [13 Regression] Wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Priority|P3 |P1 Known to work||12.2.1 Target Milestone|--- |13.0 Status|UNCONFIRMED |NEW Last reconfirmed||2023-03-30 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303 --- Comment #7 from Jakub Jelinek --- BTW, I think I got that offset >= (HOST_WIDE_INT) UINT_MAX * BITS_PER_UNIT wrong last time, if offset is equal to that, it is still representable (as UINT_MAX). So perhaps either offset > (HOST_WIDE_INT) UINT_MAX * BITS_PER_UNIT or >= (UINT_MAX + HOST_WIDE_INT_1) * BITS_PER_UNIT, depending on whether we expect the divisions to be exact or truncating. On the other side, if it is just an optimization, who cares...
[Bug rtl-optimization/109343] invalid if conversion optimization for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109343 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2023-03-30 Target||aarch64 --- Comment #1 from Richard Biener --- How can sga_var be unmapped if you don't declare it 'weak'?
[Bug c++/109278] a note without a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109278 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ee6ae8cb4793041590b479346433ed786a86985d commit r13-6941-gee6ae8cb4793041590b479346433ed786a86985d Author: Jakub Jelinek Date: Thu Mar 30 09:34:12 2023 +0200 c++: Avoid informs without a warning [PR109278] On the following testcase we emit notes in maybe_inform_about_fndecl_for_bogus_argument_init despite no warning/error being printed before it. This is for the extended floating point type conversions where pedwarn is used, and complained is used there for 2 different purposes, one is whether an unspecific error should be emitted if we haven't complained otherwise, and one whether maybe_inform_about_fndecl_for_bogus_argument_init should be called. For the 2 pedwarns, currently it sets complained to true regardless of whether pedwarn succeeded, which results in the undesirable notes printed with -w. If complained is initialized to result of pedwarn, we would emit an error later on. So, the following patch makes complained a tristate, the additional error isn't printed if complained != 0, and maybe_inform_about_fndecl_for_bogus_argument_init is called only if complained == 1, so if pedwarn returns false, we can use complained = -1 to tell later code not to emit an error and not to call maybe_inform_about_fndecl_for_bogus_argument_init. 2023-03-30 Jakub Jelinek PR c++/109278 * call.cc (convert_like_internal): If pedwarn for extended float type conversions doesn't report anything, avoid calling maybe_inform_about_fndecl_for_bogus_argument_init. * g++.dg/cpp23/ext-floating15.C: New test.
[Bug c++/109278] a note without a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109278 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |libstdc++
--- Comment #2 from Richard Biener ---
The diagnostic is intentional I think. We see
[local count: 1073741824]:
ss ={v} {CLOBBER};
std::stop_token::_Stop_state_ref::_Stop_state_ref (&ss._M_state, &ss);
std::stop_source::~stop_source (&ss);
ss ={v} {CLOBBER(eol)};
return 0;
and the call to _Stop_state_ref passes references to uninitialized 'ss'
(tree-ssa-uninit.cc:maybe_warn_pass_by_reference). The &ss argument
is a const reference and the function does
_Stop_state_ref(const _Stop_state_ref& __other) noexcept
: _M_ptr(__other._M_ptr)
{
if (_M_ptr)
_M_ptr->_M_add_owner();
}
so it inspects __other._M_ptr. It looks like for some reason the NSDMI
init of _M_ptr isn't happening?
The FE emits
;; Function std::stop_source::stop_source() (null)
;; enabled by -tree-original
<;
{
<_M_state, (const struct stop_source &) this) >;
try
{
}
catch
{
std::stop_token::_Stop_state_ref::~_Stop_state_ref (&((struct stop_source
*) this)->_M_state);
}
}
but it's all a bit convoluted? To me it looks like a library issue. Yes,
with more inlining we optimize everything away.
[Bug tree-optimization/109342] [13 Regression] Wrong code with -O2 since r13-5348-gc29d85359add80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Keywords|needs-bisection | Summary|[13 Regression] Wrong code |[13 Regression] Wrong code |with -O2|with -O2 since ||r13-5348-gc29d85359add80 --- Comment #2 from Martin Liška --- Started with r13-5348-gc29d85359add80.
[Bug ipa/109341] [12/13 Regression] ICE in merge, at ipa-modref-tree.cc:176 since r12-3142-g5c85f29537662f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109341 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Summary|[12/13 Regression] ICE in |[12/13 Regression] ICE in |merge, at |merge, at |ipa-modref-tree.cc:176 |ipa-modref-tree.cc:176 ||since ||r12-3142-g5c85f29537662f --- Comment #2 from Martin Liška --- Started with r12-3142-g5c85f29537662f.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339 --- Comment #3 from Richard Biener --- Other than that in principle maybe_warn_pass_by_reference could be enhanced by realizing a (sub-)object is passed both as const reference and non-const reference as in this case, but it would be still an odd API.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.3
[Bug tree-optimization/109342] [13 Regression] Wrong code with -O2 since r13-5348-gc29d85359add80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Mine then.
[Bug c++/109344] New: feraiseexcept produces incorrect code when optimizations are enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344 Bug ID: 109344 Summary: feraiseexcept produces incorrect code when optimizations are enabled Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: albin at yahoo dot com Target Milestone: --- At -O1, calls to feraiseexcept are inlined. But the inlined code produces incorrect results. See here, only the first function behaves as expected: https://godbolt.org/z/ncc3cjoKh The behavior persists across many versions. (A side note, I don't understand how the first function works, in order to produce a divbyzero exception it appears to divide 0 / 1, not 1 / 0, am I reading the assembly wrong?)
[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark with r10-5090-ga9a4edf0e71bba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409 Martin Liška changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #24 from Martin Liška --- Sure, let's close it.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 107409, which changed state. Bug 107409 Summary: Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark with r10-5090-ga9a4edf0e71bba https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID
[Bug target/109328] [13 Regression] Build fail in RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Kito Cheng --- I can reproduce the problem with crosstool-ng, and it has resolved by Andrew Pinski's fix, I am reviewing the dependency in the file. Plan to drop a complete version of patch later :)
[Bug target/109328] [13 Regression] Build fail in RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328 --- Comment #5 from Marc Poulhiès --- Thanks for the very quick fix (I'm the one who hit this issue)!
[Bug libstdc++/109242] C++2b std::optional::transform omits required std::remove_cv_t from return optional type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109242 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:82e8d1685a1e5fac4880e987ed9684248378bce2 commit r12-9369-g82e8d1685a1e5fac4880e987ed9684248378bce2 Author: Jonathan Wakely Date: Wed Mar 29 22:16:55 2023 +0100 libstdc++: Use std::remove_cv_t in std::optional::transform [PR109242] We need to strip cv-qualifiers from the result of the callable passed to std::optional::transform. libstdc++-v3/ChangeLog: PR libstdc++/109242 * include/std/optional (transform): Use std::remove_cv_t. * testsuite/20_util/optional/monadic/pr109242.cc: New test. (cherry picked from commit 31a909712014b75fc6ae2ca5eaa425f218bb5f32)
[Bug libstdc++/109242] C++2b std::optional::transform omits required std::remove_cv_t from return optional type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109242 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- Fixed for 12.3, thanks for the report.
[Bug rtl-optimization/108999] Maybe LRA produce inaccurate hardware register occupancy information for subreg operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108999 Lehua Ding changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Lehua Ding --- Fixed.
report a bug of gcc implementation of std::vsnprintf()
Hi,
I found a bug in the result of std::vsnprintf(), here is the test app that can
reproduce it.
I tested with g++ 11.2 and 12.2 and both have the bug, and this issue does not
happen with visual c++.
#include
#include
#include
#include
int Sprintf(std::string& s, const char* pszFormat, ...) {
va_list argptr;
va_start(argptr, pszFormat);
auto n = std::vsnprintf(nullptr, 0, pszFormat, argptr);
char* buf = (char*)malloc(n + 1);
n = std::vsnprintf(buf, n + 1, pszFormat, argptr);
s = buf;
free(buf);
va_end(argptr);
return n;
}
int main() {
std::string s, s0, s1, s2;
double d = 3.14;
//the result is wrong
Sprintf(s, "abc%.0f", d);
std::cout << "s=" << s << "\n\n";
//the result is wrong
Sprintf(s0, "%.0f", d);
std::cout << "s0=" << s0 << "\n\n";
//the printf result is correct
printf( "%.0f\n\n", d);
//now it becomes correct
Sprintf(s1, "%.0f", d);
std::cout << "s1=" << s1 << "\n\n";
//and this becomes correct too.
Sprintf(s2, "abc%.0f", d);
std::cout << "s2=" << s2 << "\n\n";
}
In a short word, printf() get the correct result, after calling it, vsnprintf()
became correct too.
my build command: g++ -o t1 t1.cpp
Thanks,
Qiang Ren
[Bug tree-optimization/107087] [13 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > Comment 0 comes from 22_locale/money_put/cons/3.cc > > make check RUNTESTFLAGS="conformance.exp=22_locale/money_put/cons/3.cc > --target_board=unix/-m32" > > (but I don't see it failing now). I was using the wrong flags, with -m32 -D_GLIBCXX_DEBUG it fails on gcc-12: Schedule of variations: unix/-m32/-D_GLIBCXX_USE_CXX11_ABI=0 Running target unix/-m32/-D_GLIBCXX_USE_CXX11_ABI=0 Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/jwakely/src/gcc/gcc-12/libstdc++-v3/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/jwakely/src/gcc/gcc-12/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... FAIL: 22_locale/money_get/cons/3.cc (test for excess errors) FAIL: 22_locale/money_put/cons/3.cc (test for excess errors) And also still fails on trunk after r13-6905: Schedule of variations: unix/-m32/-D_GLIBCXX_USE_CXX11_ABI=0 Running target unix/-m32/-D_GLIBCXX_USE_CXX11_ABI=0 Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... FAIL: 22_locale/money_get/cons/3.cc (test for excess errors) FAIL: 22_locale/money_put/cons/3.cc (test for excess errors) Comment 1 is fixed on trunk now though, thanks.
Re: report a bug of gcc implementation of std::vsnprintf()
On Thu, Mar 30, 2023 at 08:29:45AM +, Qiang Ren via Gcc-bugs wrote:
> I found a bug in the result of std::vsnprintf(), here is the test app that
> can reproduce it.
> I tested with g++ 11.2 and 12.2 and both have the bug, and this issue does
> not happen with visual c++.
gcc-bugs is not the right way to report GCC bugs, though in this case
the only bug is in your program.
You can't use the same va_list multiple times as you pass it to
std::vsnprintf, either you need to use va_copy before the first call
and use the copy in one of the two calls, or you need to va-end after
the first vsnprintf call and va_start again before the second call.
>
> #include
> #include
> #include
> #include
>
> int Sprintf(std::string& s, const char* pszFormat, ...) {
> va_list argptr;
> va_start(argptr, pszFormat);
>
> auto n = std::vsnprintf(nullptr, 0, pszFormat, argptr);
> char* buf = (char*)malloc(n + 1);
> n = std::vsnprintf(buf, n + 1, pszFormat, argptr);
> s = buf;
> free(buf);
>
> va_end(argptr);
> return n;
> }
Jakub
[Bug analyzer/107943] [11/12/13 Regression] gcc -fanalyzer hangs in openssl curve25519.c since r11-3840-gaf66094d03779377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943 --- Comment #7 from Richard Biener --- Samples: 193K of event 'cycles', Event count (approx.): 206254655627 Overhead Samples Command Shared Object Symbol 12.11% 23476 cc1 cc1 [.] ana::store_manager::get_concrete_binding 9.71% 18828 cc1 cc1 [.] hash_table, ana::concrete_binding*> >::hash_entry, false, xcallocator>::find_with_hash 6.73% 13045 cc1 cc1 [.] hash_table, ana::svalue const*> >::hash_entry, false, xcallocator>::find_slot_with_hash 5.64% 10937 cc1 libc-2.31.so [.] _int_malloc 5.20% 10087 cc1 cc1 [.] ana::region_model_manager::get_or_create_constant_svalue 5.06% 9815 cc1 libc-2.31.so [.] _int_free 4.84% 9380 cc1 cc1 [.] hash_table, ana::svalue const*> >::hash_entry, false, xcallocator>::expand 4.63% 8971 cc1 cc1 [.] hash_table, ana::element_region*> >::hash_entry, false, xcallocator>::find_with_hash 4.59% 8886 cc1 cc1 [.] iterative_hash 3.30% 6396 cc1 cc1 [.] ana::binding_cluster::bind_compound_sval 2.58% 4995 cc1 cc1 [.] ana::store::~store 2.19% 4250 cc1 cc1 [.] hash_table, ana::svalue const*> >::hash_entry, false, xcallocator>::find_with_hash looks like for larger workloads it gets memory bound - optimizing data structures (and hash functions?) might be helpful.
[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- Why should the second and third function only raise FE_INVALID?
[Bug ipa/109341] [12/13 Regression] ICE in merge, at ipa-modref-tree.cc:176 since r12-3142-g5c85f29537662f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109341 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The warning is because we unswitch the loop, so we have a separate loop for h != 0 and separate loop for h == 0. And the latter obviously invokes undefined behavior (though I get it for iteration 3 rather than 7).
[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103559 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #8 from Xi Ruoyao --- (In reply to Jakub Jelinek from comment #7) > The HW sqrt certainly handles NAN input by returning NAN output, the > question is if it is required to set some errno in that case as well or not. > One would need to check what different libcs do in that case. Glibc sets EDOM: https://sourceware.org/git/?p=glibc.git;a=blob;f=math/w_sqrt_template.c
[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103559 --- Comment #9 from Jakub Jelinek --- isless (NAN, 0.0) should be false, no, so NAN shouldn't errno = EDOM for glibc.
[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103559 --- Comment #10 from Xi Ruoyao --- (In reply to Jakub Jelinek from comment #9) > isless (NAN, 0.0) should be false, no, so NAN shouldn't errno = EDOM for > glibc. Oh, I misunderstood your question.
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2023-03-30 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Segher Boessenkool --- This still happens, and still is incredibly annoying. Left over after distclean are $ ll c++tools/ total 3620 -rw-rw-r-- 1 segher segher4781 Mar 29 10:39 Makefile -rw-rw-r-- 1 segher segher4972 Mar 29 10:39 config.cache -rwxrwxr-x 1 segher segher 2578928 Mar 29 10:39 g++-mapper-server -rw-rw-r-- 1 segher segher1319 Mar 29 10:39 resolver.d -rw-rw-r-- 1 segher segher 593464 Mar 29 10:39 resolver.o -rw-rw-r-- 1 segher segher2020 Mar 29 10:39 server.d -rw-rw-r-- 1 segher segher 518552 Mar 29 10:39 server.o
[Bug analyzer/107943] [11/12/13 Regression] gcc -fanalyzer hangs in openssl curve25519.c since r11-3840-gaf66094d03779377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943 Richard Biener changed: What|Removed |Added Last reconfirmed|2022-12-01 00:00:00 |2023-3-30 Known to fail||13.0 --- Comment #8 from Richard Biener --- Re-confirmed on trunk btw. I killed cc1 after 55min (release checking build)
[Bug tree-optimization/109342] [13 Regression] Wrong code with -O2 since r13-5348-gc29d85359add80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1d0ba4467dd9cad11eb9ff547442e3ce6292b892 commit r13-6942-g1d0ba4467dd9cad11eb9ff547442e3ce6292b892 Author: Richard Biener Date: Thu Mar 30 11:32:19 2023 +0200 tree-optimization/109342 - wrong code with edge equivalences in VN The following testcase shows a problem in how we query valitity for equivalences on edges when the edge is a backedge and thus refering to a block thats later in the iteration order we use for VN. That causes the dominated_by_p_w_unex helper to look at edge executable state that's not yet computed and thus still at optimistic not executable state. The following makes sure to use a plain dominance check in these cases. PR tree-optimization/109342 * tree-ssa-sccvn.cc (vn_nary_op_get_predicated_value): New overload for edge. When that edge is a backedge use dominated_by_p directly. * g++.dg/torture/pr109342.C: New testcase.
[Bug tree-optimization/109342] [13 Regression] Wrong code with -O2 since r13-5348-gc29d85359add80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 109342, which changed state. Bug 109342 Summary: [13 Regression] Wrong code with -O2 since r13-5348-gc29d85359add80 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
I get the same result for all of -O0/-O1/-O2, all 3 functions raise both
exceptions and that is correct, glibc has removed the inline versions some time
ago:
https://sourceware.org/pipermail/libc-alpha/2020-March/111753.html
The bug was on the glibc side:
both the
/* One example of an invalid operation is 0.0 / 0.0. */
float __f = 0.0;
# ifdef __SSE_MATH__
__asm__ __volatile__ ("divss %0, %0 " : : "x" (__f));
and
float __f = 1.0;
float __g = 0.0;
# ifdef __SSE_MATH__
__asm__ __volatile__ ("divss %1, %0" : : "x" (__f), "x" (__g));
part, because glibc didn't tell the compiler the inline assembly actually
modifies the register.
So, the first one was supposed to be
__asm__ __volatile__ ("divss %0, %0 " : "+x" (__f));
and the second
__asm__ __volatile__ ("divss %1, %0" : "+x" (__f) : "x" (__g));
Not a bug on the GCC side and on glibc side it has been fixed by the removal of
the inline version.
[Bug ipa/109341] [12/13 Regression] ICE in merge, at ipa-modref-tree.cc:176 since r12-3142-g5c85f29537662f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109341 Jan Hubicka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Jan Hubicka --- mine.
[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561 --- Comment #25 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:04b0a7b1a6d9e0f3782888f1ebf187c26690038b commit r13-6943-g04b0a7b1a6d9e0f3782888f1ebf187c26690038b Author: Richard Biener Date: Wed Mar 29 13:49:24 2023 +0200 tree-optimization/107561 - reduce -Wstringop-overflow false positives The following tells pointer-query to prefer a zero size when we are querying for the size range for a write into an object we've determined is of zero size. That avoids diagnostics about really varying size arguments that just get a meaningful range for example because they are multiplied by an element size. I've adjusted only one call to get_size_range since that's what I have a testcase for. PR tree-optimization/107561 * gimple-ssa-warn-access.cc (get_size_range): Add flags argument and pass it on. (check_access): When querying for the size range pass SR_ALLOW_ZERO when the known destination size is zero. * g++.dg/pr71488.C: Remove XFAILed bogus diagnostic again. * g++.dg/warn/Warray-bounds-16.C: Likewise.
[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #26 from Richard Biener --- Fixed.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 107561, which changed state. Bug 107561 Summary: [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||marxin at gcc dot gnu.org
Keywords|needs-reduction |
Last reconfirmed||2023-03-30
--- Comment #3 from Martin Liška ---
Reduced test-case:
$ cat pr108640.i
int option_mask32;
enum {
OPTBIT_F = 12,
OPTBIT_R,
OPTBIT_Z,
OPTBIT_c,
OPTBIT_t,
OPT_t = 1 << OPTBIT_t
} ls_main() {
option_mask32 |= OPT_t;
}
$ ./xgcc -B. ~/Programming/testcases/pr108640.i -c -Os
during RTL pass: final
/home/marxin/Programming/testcases/pr108640.i: In function ‘ls_main’:
/home/marxin/Programming/testcases/pr108640.i:12:1: internal compiler error: in
change_address_1, at emit-rtl.cc:2287
12 | }
| ^
0xee4b72 change_address_1
/home/marxin/Programming/gcc/gcc/emit-rtl.cc:2287
0xee5684 adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int,
int, poly_int<1u, long>)
/home/marxin/Programming/gcc/gcc/emit-rtl.cc:2421
0x190e4e3 output_iorsi3(rtx_def**)
/home/marxin/Programming/gcc/gcc/config/m68k/m68k.cc:5513
0x1fd17bd output_255
/home/marxin/Programming/gcc/gcc/config/m68k/m68k.md:3779
0xf64f4f get_insn_template(int, rtx_insn*)
/home/marxin/Programming/gcc/gcc/final.cc:2029
0xf66b5e final_scan_insn_1
/home/marxin/Programming/gcc/gcc/final.cc:2774
0xf66fd2 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/marxin/Programming/gcc/gcc/final.cc:2887
0xf64d79 final_1
/home/marxin/Programming/gcc/gcc/final.cc:1979
0xf69bbc rest_of_handle_final
/home/marxin/Programming/gcc/gcc/final.cc:4240
0xf69f1a execute
/home/marxin/Programming/gcc/gcc/final.cc:4318
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344 Xi Ruoyao changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Xi Ruoyao --- INVALID then.
[Bug c++/108887] [13 Regression] ICE in process_function_and_variable_attributes since r13-3601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887 --- Comment #9 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5 commit r13-6944-ga23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5 Author: Jason Merrill Date: Mon Mar 6 15:33:45 2023 -0500 c++: lambda mangling alias issues [PR107897] In 107897, by the time we are looking at the mangling clash, the alias has already been removed from the symbol table by analyze_functions, so we can't look at n->cpp_implicit_alias. So just assume that it's an alias if it's internal. In 108887 the problem is that removing the mangling alias from the symbol table confuses analyze_functions, because it ended up as first_analyzed somehow, so it becomes a dangling pointer. So instead we call reset() to neutralize the alias. To make this work for variables, I needed to move reset() from cgraph_node to symtab_node. PR c++/107897 PR c++/108887 gcc/ChangeLog: * cgraph.h: Move reset() from cgraph_node to symtab_node. * cgraphunit.cc (symtab_node::reset): Adjust. Also call remove_from_same_comdat_group. gcc/cp/ChangeLog: * decl2.cc (record_mangling): Use symtab_node::reset. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-lambda3.C: Use -flto if supported. * g++.dg/cpp0x/lambda/lambda-mangle7.C: New test.
[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897 --- Comment #7 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5 commit r13-6944-ga23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5 Author: Jason Merrill Date: Mon Mar 6 15:33:45 2023 -0500 c++: lambda mangling alias issues [PR107897] In 107897, by the time we are looking at the mangling clash, the alias has already been removed from the symbol table by analyze_functions, so we can't look at n->cpp_implicit_alias. So just assume that it's an alias if it's internal. In 108887 the problem is that removing the mangling alias from the symbol table confuses analyze_functions, because it ended up as first_analyzed somehow, so it becomes a dangling pointer. So instead we call reset() to neutralize the alias. To make this work for variables, I needed to move reset() from cgraph_node to symtab_node. PR c++/107897 PR c++/108887 gcc/ChangeLog: * cgraph.h: Move reset() from cgraph_node to symtab_node. * cgraphunit.cc (symtab_node::reset): Adjust. Also call remove_from_same_comdat_group. gcc/cp/ChangeLog: * decl2.cc (record_mangling): Use symtab_node::reset. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-lambda3.C: Use -flto if supported. * g++.dg/cpp0x/lambda/lambda-mangle7.C: New test.
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #5 from Jonathan Wakely --- c++tools/Makefile.in has: mostlyclean:: rm -f $(MAPPER.O) clean:: rm -f g++-mapper-server$(exeext) distclean:: rm -f config.log config.status config.h Should distclean have clean as a prerequisite and clean have mostlyclean as a prerequisite? That would still leave config.cache and Makefile and the .d fragments though.
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #6 from Jonathan Wakely --- Also, after 'make clean' you can no longer do 'make all' c++tools$ make clean all # --enable-maintainer-mode to rebuild /home/jwakely/src/gcc/gcc/c++tools/configure, or make MAINTAINER=touch # --enable-maintainer-mode to rebuild /home/jwakely/src/gcc/gcc/c++tools/config.h.in, or make MAINTAINER=touch rm -f g++-mapper-server g++ -g -O2 -fno-exceptions -fno-rtti -I/home/jwakely/src/gcc/gcc/c++tools/../libcody -I/home/jwakely/src/gcc/gcc/c++tools/../include -I/home/jwakely/src/gcc/gcc/c++tools/../gcc -I. -I../gcc \ -MMD -MP -MF server.d -c -o server.o /home/jwakely/src/gcc/gcc/c++tools/server.cc g++ -static-libstdc++ -static-libgcc -o g++-mapper-server server.o resolver.o ../libcody/libcody.a ../libiberty/libiberty.a g++-mapper-server ../gcc/g++-mapper-server make: g++-mapper-server: No such file or directory make: *** [Makefile:101: ../gcc/g++-mapper-server] Error 127
[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103559 --- Comment #11 from Jakub Jelinek --- Actually, I was just misreading the tree dumps, we use hw insn for x u>= 0.0, which is UNGE_EXPR, so it is true if x is NAN or GE_EXPR, or as described in the tree-call-cdce.cc comment: y = sqrt (x); ==> if (__builtin_isless (x, 0)) y = sqrt (x); else y = IFN_SQRT (x); So we don't need to inspect anything on the libc sides, we already use the hw insn even for NANs. All we need to do is to use the ranger in tree-call-cdce.cc or perhaps later, and fold the x UNGE_EXPR 0.0 into true whenever frange says so (i.e. that the range is a subset of [-0.0, +INF] NAN).
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #7 from Segher Boessenkool --- Thank you for looking at this! (In reply to Jonathan Wakely from comment #5) > c++tools/Makefile.in has: > > mostlyclean:: > rm -f $(MAPPER.O) > > clean:: > rm -f g++-mapper-server$(exeext) > > distclean:: > rm -f config.log config.status config.h > > > Should distclean have clean as a prerequisite and clean have mostlyclean as > a prerequisite? That is what all other Makefiles do, and that makes sense yes. Is it that simple? I'll test with that now. > That would still leave config.cache and Makefile and the .d fragments though. Yup, but those I know how to handle :-)
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #8 from Segher Boessenkool --- (In reply to Jonathan Wakely from comment #6) > Also, after 'make clean' you can no longer do 'make all' Of course you cannot. Where do you see this?
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #9 from Segher Boessenkool --- (In reply to Segher Boessenkool from comment #8) > (In reply to Jonathan Wakely from comment #6) > > Also, after 'make clean' you can no longer do 'make all' > > Of course you cannot. Where do you see this? Erm, scratch that, confusing clean and distclean myself now, heh.
[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
--- Comment #11 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #9)
> It looks like what we want for this test is actually !isgreaterequal() not
> isless(), since we want to exclude the possibility of a NAN. Like this:
>
> float test (float x)
> {
> if (!__builtin_isgreaterequal (x, 0.0))
> __builtin_unreachable();
> return sqrtf (x);
> }
No, what we emit for sqrtf is effectively:
if (!__builtin_isless (x, 0.0))
asm ("sqrtss %0, %0" : "+x" (x));
else
x = sqrtf (x); // The library version
return x;
So, the
if (__builtin_isless (x, 0.0)
__builtin_unreachable ();
is all we need.
We should either ask in tree-call-cdce.cc before trying to create this whether
x range is [-0.0, +Inf] NAN or some subset thereof, in that case just use
the .SQRT internal call, or if it is [-Inf, nextafterf (-0.0, -Inf)] or subset
thereof,
then use the library call only.
Or try to fold it in vrp2 or when, but in that case we don't know that easily
whether
the comparison can be optimized away completely (it still raises exceptions on
sNaN).
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #10 from Jonathan Wakely --- This seems like an improvement ... --- a/c++tools/Makefile.in +++ b/c++tools/Makefile.in @@ -22,6 +22,7 @@ libexecdir := @libexecdir@ target_noncanonical := @target_noncanonical@ gcc_version := $(shell @get_gcc_base_ver@ $(srcdir)/../gcc/BASE-VER) libexecsubdir := $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version) +INSTALL := @INSTALL@ INSTALL_PROGRAM := @INSTALL_PROGRAM@ INSTALL_STRIP_PROGRAM := $(srcdir)/../install-sh -c -s AUTOCONF := @AUTOCONF@ @@ -41,13 +42,14 @@ all:: mostlyclean:: rm -f $(MAPPER.O) -clean:: +clean:: mostlyclean rm -f g++-mapper-server$(exeext) -distclean:: - rm -f config.log config.status config.h +distclean:: clean + rm -f config.log config.status config.h config.cache Makefile + rm -f $(MAPPER.O:%.o=%.d) -maintainer-clean:: +maintainer-clean:: distclean install:: @@ -132,6 +134,6 @@ config.h: config.status config.h.in config.status: $(srcdir)/configure $(srcdir)/config.h.in if test -x $@; then ./$@ -recheck; else $< @configure_args@; fi -.PHONY: all check clean distclean maintainer-clean +.PHONY: all check mostlyclean clean distclean maintainer-clean -include $(MAPPER.O:.o=.d)
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #11 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #10) > @@ -22,6 +22,7 @@ libexecdir := @libexecdir@ > target_noncanonical := @target_noncanonical@ > gcc_version := $(shell @get_gcc_base_ver@ $(srcdir)/../gcc/BASE-VER) > libexecsubdir := $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version) > +INSTALL := @INSTALL@ Without this, the 'all' target in c++tools is broken. It only works as part of a bootstrap because the top-level Makefile sets INSTALL in the environment when recursively calling 'make -C c++tools all' > INSTALL_PROGRAM := @INSTALL_PROGRAM@ > INSTALL_STRIP_PROGRAM := $(srcdir)/../install-sh -c -s > AUTOCONF := @AUTOCONF@ > @@ -41,13 +42,14 @@ all:: > mostlyclean:: > rm -f $(MAPPER.O) > > -clean:: > +clean:: mostlyclean > rm -f g++-mapper-server$(exeext) > > -distclean:: > - rm -f config.log config.status config.h > +distclean:: clean > + rm -f config.log config.status config.h config.cache Makefile > + rm -f $(MAPPER.O:%.o=%.d) > > -maintainer-clean:: > +maintainer-clean:: distclean These ensure the clean targets progressively clean more, instead of only removing disjoint sets of files, so that all the *clean targets need to be run to clean up properly. > @@ -132,6 +134,6 @@ config.h: config.status config.h.in > config.status: $(srcdir)/configure $(srcdir)/config.h.in > if test -x $@; then ./$@ -recheck; else $< @configure_args@; fi > > -.PHONY: all check clean distclean maintainer-clean > +.PHONY: all check mostlyclean clean distclean maintainer-clean And this was just missing. There might be other problems, but this means that "make distclean" works, and you can also do "make clean all" in the c++tools dir (rather than only being able to build c++tools from the top-level).
[Bug target/109104] [13 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1171 with -fzero-call-used-regs=all -march=rv64gv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Last reconfirmed||2023-03-30 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Started with r13-2819-gb4feb49cf308b3, it was rejected before the revision with: :1:17: sorry, unimplemented: argument ‘all’ is not supported for ‘-fzero-call-used-regs’ on this target
[Bug c++/108887] [13 Regression] ICE in process_function_and_variable_attributes since r13-3601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Jason Merrill --- Fixed.
[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jason Merrill --- Fixed.
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #12 from Jonathan Wakely --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614893.html
[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344 --- Comment #4 from albin --- Thanks for the info. If it was fixed three years ago how come it is still seen when using gcc (trunk) on Compiler Explorer? Is Compiler Explorer using an obsolete glibc?
[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344 --- Comment #5 from Xi Ruoyao --- (In reply to albin from comment #4) > Thanks for the info. If it was fixed three years ago how come it is still > seen when using gcc (trunk) on Compiler Explorer? Is Compiler Explorer using > an obsolete glibc? It uses Glibc-2.31: https://godbolt.org/z/h348q7fbh
[Bug fortran/109345] New: class(*) variable that is a string array is not handled correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345 Bug ID: 109345 Summary: class(*) variable that is a string array is not handled correctly Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: lchilutti at gmail dot com Target Milestone: --- program test implicit none character(len=255) :: str_array(2) !< Array of strings str_array(1) = "" str_array(2) = "" str_array(1) = "2880:2880,1:2160::1:1,1:2160" str_array(2) = "1:1440,2160:2160::2880:1441,2160:2160" call foo(str_array) !< class(*) call foo2(str_array) !< char type call foo3(str_array) !< class(*) with str copy contains subroutine foo ( var) !< Uses class(*) class(*), intent(in) :: var(:) integer :: i select type (var) type is (character(len=*)) print *, "Using class(*)" print *, "The size of var:", size(var) do i = 1, size(var) print *, len_trim(var(i)), "data:", trim(var(i)) enddo end select end subroutine subroutine foo2 (var) !< Uses char type character(len=*), intent(in) :: var(:) integer :: i print *, "Not using class(*)" print *, "The size of var:", size(var) do i = 1, size(var) print *, len_trim(var(i)), "data:", trim(var(i)) enddo end subroutine subroutine foo3 (var) !< Uses class(*) with a workaround class(*), intent(in) :: var(:) integer :: i character(len=:), dimension(:), allocatable :: str select type (var) type is (character(len=*)) str = var !< if you copy the class(*) var to an allocatable string it works print *, "Using class(*), with string copy workaround" print *, "The size of str:", size(str) do i = 1, size(str) print *, len_trim(str(i)), "data:", trim(str(i)) enddo end select end subroutine end program If I compile the above program with gfortran (gcc version 12.2.0), I get the following output: Using class(*) The size of var: 2 28 data:2880:2880,1:2160::1:1,1:2160 255 data:880:2880,1:2160::1:1,1:2160 1 Not using class(*) The size of var: 2 28 data:2880:2880,1:2160::1:1,1:2160 37 data:1:1440,2160:2160::2880:1441,2160:2160 Using class(*), with string copy workaround The size of str: 2 28 data:2880:2880,1:2160::1:1,1:2160 37 data:1:1440,2160:2160::2880:1441,2160:2160 You can see that when we give an array of strings as an argument to a function using class(*) and select type, the string returned within the select type function is incorrect. We found a workaround in which we can copy the class(*) input variable to an allocatable string within the select type statement, but we should not have to do this.
[Bug rtl-optimization/109343] invalid if conversion optimization for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109343
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Andrew Pinski ---
If we mark sga_var as weak then there is no ifcvt.
extern int sga_mapped;
extern int sga_var __attribute__((weak));
int func(int j){
int i=0;
if(sga_mapped)
i=i+sga_var;
return i;
}
[Bug tree-optimization/81958] [10/11/12/13 Regression] spurious -Wmaybe-uninitialized warning in gcc-8, or with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81958 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #8 from Richard Biener --- We see [count: 0]: # eq_7 = PHI # ivtmp.7_23 = PHI <0(2), ivtmp.7_24(8)> _25 = (unsigned int) ivtmp.7_23; if (maxidx_15(D) > _25) goto ; [0.00%] else goto ; [0.00%] // loop exit [count: 0]: if (maxidx_15(D) == _25) goto ; [0.00%] else goto ; [0.00%] [count: 0]: # eq_9 = PHI printk (eq_9); [tail call] return; and the appearant uninit use is on the 10->7 edge, when maxidx != _25 but at the same time maxidx > _25. We don't realize that the maxidx == _25 condition is always true. The possible easiest way is probably to rewrite the in-loop condition to maxid != _25 somewhere (ivcanon?). uninit analysis itself just sees maxid <= _25 && maxid ==_25 as the initialized cases - it could possibly analyze how _25 evolves when defined in a loop to further optimize this to true.
[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
--- Comment #12 from Jakub Jelinek ---
WIP which still doesn't work:
--- gcc/value-query.cc.jj 2023-03-23 15:25:47.069740988 +0100
+++ gcc/value-query.cc 2023-03-30 14:56:58.809298424 +0200
@@ -230,9 +230,11 @@ range_query::get_tree_range (vrange &r,
default:
break;
}
- if (BINARY_CLASS_P (expr))
+ if (BINARY_CLASS_P (expr) || COMPARISON_CLASS_P (expr))
{
- range_op_handler op (TREE_CODE (expr), type);
+ range_op_handler op (TREE_CODE (expr),
+ BINARY_CLASS_P (expr) ? type
+ : TREE_TYPE (TREE_OPERAND (expr, 0)));
if (op)
{
Value_Range r0 (TREE_TYPE (TREE_OPERAND (expr, 0)));
--- gcc/tree-call-cdce.cc.jj2023-01-02 09:32:45.940944935 +0100
+++ gcc/tree-call-cdce.cc 2023-03-30 14:54:25.248544702 +0200
@@ -36,6 +36,7 @@ along with GCC; see the file COPYING3.
#include "builtins.h"
#include "internal-fn.h"
#include "tree-dfa.h"
+#include "gimple-range.h"
/* This pass serves two closely-related purposes:
@@ -425,12 +426,9 @@ comparison_code_if_no_nans (tree_code co
null tree. */
static void
-gen_one_condition (tree arg, int lbub,
- enum tree_code tcode,
- const char *temp_name1,
- const char *temp_name2,
- vec conds,
- unsigned *nconds)
+gen_one_condition (tree arg, int lbub, enum tree_code tcode,
+ const char *temp_name1, const char *temp_name2,
+ vec conds, unsigned *nconds, gimple *stmt)
{
if (!HONOR_NANS (arg))
tcode = comparison_code_if_no_nans (tcode);
@@ -451,10 +449,24 @@ gen_one_condition (tree arg, int lbub,
gimple_assign_set_lhs (stmt1, tempn);
tempc = create_tmp_var (boolean_type_node, temp_name2);
- stmt2 = gimple_build_assign (tempc,
- fold_build2 (tcode,
- boolean_type_node,
- tempn, lbub_real_cst));
+ tree tcond = build2 (tcode, boolean_type_node, arg, lbub_real_cst);
+ int_range_max r;
+ range_query *q = get_range_query (cfun);
+ if (q == get_global_range_query ())
+q = enable_ranger (cfun);
+ /* Ask the ranger whether it knows the condition will be always false or
+ always true. */
+ if (!q->range_of_expr (r, tcond, stmt) || r.undefined_p ())
+tcond = NULL_TREE;
+ else if (r.upper_bound () == 0)
+tcond = boolean_false_node;
+ else if (r.lower_bound () == 1)
+tcond = boolean_true_node;
+ else
+tcond = NULL_TREE;
+ if (!tcond)
+tcond = fold_build2 (tcode, boolean_type_node, tempn, lbub_real_cst);
+ stmt2 = gimple_build_assign (tempc, tcond);
tempcn = make_ssa_name (tempc, stmt2);
gimple_assign_set_lhs (stmt2, tempcn);
@@ -475,16 +487,15 @@ gen_one_condition (tree arg, int lbub,
for lower bound check, one for upper bound check. */
static void
-gen_conditions_for_domain (tree arg, inp_domain domain,
- vec conds,
- unsigned *nconds)
+gen_conditions_for_domain (tree arg, inp_domain domain, vec conds,
+ unsigned *nconds, gimple *stmt)
{
if (domain.has_lb)
gen_one_condition (arg, domain.lb,
(domain.is_lb_inclusive
? UNGE_EXPR : UNGT_EXPR),
"DCE_COND_LB", "DCE_COND_LB_TEST",
- conds, nconds);
+ conds, nconds, stmt);
if (domain.has_ub)
{
@@ -496,7 +507,7 @@ gen_conditions_for_domain (tree arg, inp
(domain.is_ub_inclusive
? UNLE_EXPR : UNLT_EXPR),
"DCE_COND_UB", "DCE_COND_UB_TEST",
- conds, nconds);
+conds, nconds, stmt);
}
}
@@ -518,9 +529,8 @@ gen_conditions_for_domain (tree arg, inp
and *NCONDS is the number of logical conditions. */
static void
-gen_conditions_for_pow_cst_base (tree base, tree expn,
-vec conds,
- unsigned *nconds)
+gen_conditions_for_pow_cst_base (tree base, tree expn, vec conds,
+unsigned *nconds, gimple *stmt)
{
inp_domain exp_domain;
/* Validate the range of the base constant to make
@@ -532,11 +542,9 @@ gen_conditions_for_pow_cst_base (tree ba
real_from_integer (&mv, TYPE_MODE (TREE_TYPE (base)), 256, UNSIGNED);
gcc_assert (!real_less (&mv, &bcv));
- exp_domain = get_domain (0, false, false,
- 127, true, false);
+ exp_domain = get_domain (0, false, false, 127, true, false);
- gen_conditions_for_domain (expn, exp_domain,
- conds, nconds);
+ gen_conditions_for_domain (expn, exp_domain, conds, nconds, stmt);
}
/* Generate error condition code for pow calls with
@@ -554,9 +562,8 @@
[Bug middle-end/85563] [10/11/12/13 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563 Richard Biener changed: What|Removed |Added CC||amacleod at redhat dot com, ||rguenth at gcc dot gnu.org Last reconfirmed|2021-04-15 00:00:00 |2023-3-30 --- Comment #23 from Richard Biener --- Re-confirmed. On the testcase in comment#6 we have before EVRP : Vframe_list.0_1 = Vframe_list; a.1_17 = (long int) Vframe_list.0_1; _15 = (unsigned int) a.1_17; _13 = _15 & 7; _10 = _13 == 3; if (_13 != 3) goto ; [INV] else goto ; [INV] : __builtin_unreachable (); : # frame1_6 = PHI # tail_7 = PHI a.1_19 = (long int) tail_7; _20 = (unsigned int) a.1_19; _21 = _20 & 7; _22 = _21 == 3; if (_21 == 3) goto ; [INV] else goto ; [INV] : _25 = tail_7 + 18446744073709551613; _26 = __builtin_assume_aligned (_25, 8); frame1_16 = _26->u.s.car; tail_18 = _26->u.s.u.cdr; goto ; [INV] : do_switch_frame (frame1_6); and we fail to realize we are never exiting the loop in the first iteration. The diagnostic happens because we run into loop header copying which then results in a jump around the loop with an obviously uninitialized argument to frame1_6. And that's because we have thrown away the __builtin_unreachable before loop header copying (in VRP1, after the first threadfull). Re-ordering CH before VRP fails to optimize even when I also put a copyprop between CH and VRP. We then see [local count: 118111600]: # PT = nonlocal escaped null Vframe_list.0_1 = Vframe_list; a.1_12 = (long int) Vframe_list.0_1; _10 = (unsigned int) a.1_12; # RANGE [irange] Lisp_Type [0, 7] NONZERO 0x7 _8 = _10 & 7; if (_8 != 3) goto ; [0.00%] else goto ; [100.00%] [count: 0]: __builtin_unreachable (); [local count: 118111600]: a.1_21 = (long int) Vframe_list.0_1; _22 = (unsigned int) a.1_21; # RANGE [irange] Lisp_Type [0, 7] NONZERO 0x7 _23 = _22 & 7; if (_23 == 3) but for some reason VRP doesn't optimize the second compare. We'd probably need to value-number here (loop header copying does, but only parts of the function and not including this leading block). So somewhat of a pass ordering issue. The next CSE is DOM and then PRE.
[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #13 from Jakub Jelinek ---
Created attachment 54789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54789&action=edit
gcc13-pr91645.patch
This seems to work right on the testcase I've been trying:
float sqrtf (float);
float foo (float x) { return sqrtf (x); }
float bar (float x) { if (__builtin_isless (x, 0)) __builtin_unreachable ();
return sqrtf (x); }
float baz (float x) { if (!__builtin_isless (x, 0)) __builtin_unreachable ();
return sqrtf (x); }
float qux (float x) { x = x * x; return sqrtf (x); }
Do we want this for GCC 13, or at least parts of it like the range-op-float.cc
fixes and/or the value-range.cc change, or defer everything for GCC 14?
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #25 from Jakub Jelinek --- > Anyway, as I said for the second version, it would be nice to also try > subvariants: > // relayout_decl (DECL_RESULT (new_fndecl)); > for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN > (parm)) > relayout_decl (parm); > targetm.target_option.relayout_function (new_fndecl); > // aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl); > and > relayout_decl (DECL_RESULT (new_fndecl)); > // for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN > (parm)) > //relayout_decl (parm); > targetm.target_option.relayout_function (new_fndecl); > // aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl); > and > // relayout_decl (DECL_RESULT (new_fndecl)); > // for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN > (parm)) > //relayout_decl (parm); > targetm.target_option.relayout_function (new_fndecl); > aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl); > so see if the comparison failure is fixed by the result relayout, or by > argument > relayout or by the aggregate_value_p call actually having some side-effects > other than return value. Of those three subvariants, only the third one passed the build without the comparison failure.
[Bug target/109104] [13 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1171 with -fzero-call-used-regs=all -march=rv64gv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104 Kito Cheng changed: What|Removed |Added Status|NEW |ASSIGNED CC||kito at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pan2.li at intel dot com --- Comment #4 from Kito Cheng --- Pan Li from Intel is working on fixing that
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #29 from Jakub Jelinek --- So aggregate_value_p has some side-effects other than return value then? Ugh. Anyway, my patch intention has been to avoid the relayouts. So, just calling aggregate_value_p there or perhaps instead later when we finalize DECL_RESULT and the like is an option, just would like to understand what side-effects it has. Will step through on the cross-compiler.
[Bug c++/105221] [10/11/12/13 Regression] gcc rejects true ? [](auto) noexcept {} : [](int) {} in C++17+ (works for C++14) since r7-4383-g51dc660315ef83dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221
--- Comment #6 from Jason Merrill ---
Reduced:
void (*p)(int) = [](auto) noexcept {};
[Bug c++/105221] [10/11/12/13 Regression] gcc rejects true ? [](auto) noexcept {} : [](int) {} in C++17+ (works for C++14) since r7-4383-g51dc660315ef83dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug middle-end/109128] [Offload][OpenMP][OpenACC] Static linking with unused offload function will lead to mismatch number of offload fn/symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128 --- Comment #3 from Tobias Burnus --- My initial thought was to handle it via lto1. This works well if all relevant files are compiled with "-flto" as then the callers of the offload functions, the offload functions themselves are available, permitting to generate __OFFLOAD_TABLE__ directly. However, if -flto is not used or not used for all translation units (with offload code), this approach will fail due to visibility problems. Namely, the offload functions have local binding. This could be solved by forcing global binding (with visibility hidden), but this approach will fail if the assembler name is not unique. * * * Thus, placing the symbols into a section will work (current behavior), except that the linker might remove symbols (this bug) and one needs to hope that the linking order is the same on the host as it is with LTO. Still remains the question how to handle this PR...
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #21 from Jan Hubicka --- Zen 1-3 changes were intentional in the original tuning patch (it is also briefly mentioned in the commit message). By allowing 256 bit AVX moves instead of 64bit integer moves (or 128bit) we can move bigger blocks of memory without loops and it was faster in micro-benchmarks I made on all zens, even on znver1. We also automatically go for 128bit moves when ISA allows that. We could revert that part of backport, but won't we get same hangs with -march=znver4 or core512 which also enables avx512 moves? (I am rebuilding gcc12 to see what happens)
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #22 from Jakub Jelinek --- Sure. The point was to avoid regressions on the release branch because of so big changes for the tunings which were supported before already. So we might want both the LRA changes and perhaps zen1-3 reversion.
[Bug c++/105644] ICE in a fold expression with a requires expression: in iterative_hash_template_arg, at cp/pt.cc:1805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105644 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #30 from Jakub Jelinek --- So, if I add the --- a/gcc/tree-inline.cc +++ b/gcc/tree-inline.cc @@ -2787,6 +2787,7 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl, profile_count count) /* Get clean struct function. */ push_struct_function (new_fndecl, true); targetm.target_option.relayout_function (new_fndecl); + aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl); /* We will rebuild these, so just sanity check that they are empty. */ gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL); I see 5 calls of this in this spot, two with int return type, one with TFmode floating one, one with uint and one with bool. aggregate_value_p calls targetm.calls.return_in_memory but I don't see sparc_return_in_memory to have any side-effects other than return value. Next it calls reg = hard_function_value (type, 0, fntype, 0); which does allocate a REG rtx, but doesn't save it anywhere. It then calls fntype_abi and hard_regno_nregs and predefined_function_abi::clobbers_full_reg_p, but I don't see any side-effects in those either. Nothing seems to cache its results in any way. Confused...
[Bug tree-optimization/109327] [13 Regression] ICE on valid code at -O1 and above with "-fno-tree-ccp": Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109327 Andrew Pinski changed: What|Removed |Added Summary|ICE on valid code at -O1|[13 Regression] ICE on |and above with |valid code at -O1 and above |"-fno-tree-ccp":|with "-fno-tree-ccp": |Segmentation fault |Segmentation fault Target Milestone|--- |13.0
[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #8 from Martin Jambor ---
Thanks a lot for the testcase. The divisions must always be exact.
After having one more look, I moved the check a bit earlier still and am
currently testing this:
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -2086,7 +2086,9 @@ determine_known_aggregate_parts (struct
ipa_func_body_info *fbi,
whether its value is clobbered any other dominating one. */
if ((content->value.pass_through.formal_id >= 0
|| content->value.pass_through.operand)
- && !clobber_by_agg_contents_list_p (all_list, content))
+ && !clobber_by_agg_contents_list_p (all_list, content)
+ && (content->offset + content->size - arg_offset
+ <= (HOST_WIDE_INT) UINT_MAX * BITS_PER_UNIT))
{
struct ipa_known_agg_contents_list *copy
= XALLOCA (struct ipa_known_agg_contents_list);
[Bug c++/96464] GCC accepts 'auto' in template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96464 Patrick Palka changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=109338| CC||cjdb.ns at gmail dot com --- Comment #3 from Patrick Palka --- *** Bug 109338 has been marked as a duplicate of this bug. ***
[Bug c++/109338] `S auto>` isn't valid C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109338 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=96464 | Resolution|--- |DUPLICATE --- Comment #2 from Patrick Palka --- I reckon it makes sense to call this a dup of PR96464 even, since we incorrectly accept with or without the type constraint. *** This bug has been marked as a duplicate of bug 96464 ***
[Bug c++/109337] c++2a test concepts4.C passes when it should fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109337 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #7 from Patrick Palka --- dup of PR102419 AFAICT *** This bug has been marked as a duplicate of bug 102419 ***
[Bug c++/102419] [11/12/13 Regression][concepts] return-type-requirement of "Y" does not check that T::type actually exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419 Patrick Palka changed: What|Removed |Added CC||cjdb.ns at gmail dot com --- Comment #8 from Patrick Palka --- *** Bug 109337 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970 --- Comment #15 from Martin Uecker --- Thanks. I still wonder whether the original example should be added to the test suite?
[Bug c++/109323] No error when neither of return_value or return_void is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323 --- Comment #2 from Enrico Maria De Angelis --- Created attachment 54790 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54790&action=edit Attachment for report 109323
[Bug debug/109346] New: RFE add DW_AT_location to DW_TAG_subprogram
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109346 Bug ID: 109346 Summary: RFE add DW_AT_location to DW_TAG_subprogram Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: woodard at redhat dot com Target Milestone: --- There is a currently an issue filed against the DWARF5 standard that asks for DW_AT_location to be the DW_TAG_subprogram and DW_TAG_inlined_subprogram. https://dwarfstd.org/issues/221105.1.html At least for DW_TAG_subprogram the issue seems to have fairly widespread support. Due to the general permissiveness of the DWARF standard, I have found no place in the DWARF5 standard where it says that you can't do this currently even without a textual change in the future DWARF6 standard. In addition to the reasons listed in the DWARF issue, there are a some additional reasons to have it. First of all there is DW_AT_GNU_vector. Because there is ambiguity in the calling convention for array types vs vector types, DW_AT_GNU_vector is required so that GDB can infer using the platform standard ABI where the return value of a function would be located. This is discussed here: https://lists.dwarfstd.org/pipermail/dwarf-discuss/2023-March/002212.html With a location on a DW_AT_subprogram the needs of GDB could be met without DW_AT_GNU_vector. Furthermore, elfutils libdw has the following function which tries to find the location of a function's return value. /* Return location expression to find return value given a DW_TAG_subprogram, DW_TAG_subroutine_type, or similar DIE describing function itself (whose DW_AT_type attribute describes its return type). The given DIE must come from the given module. Returns -1 for errors. Returns zero if the function has no return value (e.g. "void" in C). Otherwise, *LOCOPS gets a location expression to find the return value, and returns the number of operations in the expression. The pointer is permanently allocated at least as long as the module is live. */ extern int dwfl_module_return_value_location (Dwfl_Module *mod, Dwarf_Die *functypedie, const Dwarf_Op **locops); This currently requires a libebl backend for the architecture that knows the standard ABI for the particular return type. And it would indeed give the wrong answer currently if the function doesn't follow the standard calling convention. The problem is with the increasing use of LTO, particularly within GNU/Linux distros,the number of places where this function cannot correctly determine the location of the return value is greatly increased. This is also true for static functions, since programmers are being taught to be more careful with their exported interfaces and they recognize the performance advantages given by optimization passes that use a non-standard calling convention for static functions the number of static functions is increasing. The only really contested point of the proposal is what to do about DW_TAG_inlined_subprogram. However, not adding DW_AT_location to DW_TAG_inlined_subprogram would just be a quality of implementation issue and so it could be omitted for the time being. How to add the location information is not disputed but whether it would be possible for the compiler to correctly emit it, and how much additional DWARF would be required to implement that feature. It would end up being a huge location list for all the places where the inlined subprogram is called. For the moment, I think everyone would be happy if DW_AT_location were just applied to DW_TAG_subprogram and DW_TAG_inlined_subprogram were skipped.
[Bug c++/84075] [10/11/12/13 Regression] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |10.5
CC||ppalka at gcc dot gnu.org
Summary|Template parameter not |[10/11/12/13 Regression]
|resolved: invalid |Template parameter not
|application of ‘sizeof’ to |resolved: invalid
|incomplete type |application of ‘sizeof’ to
|‘boost::serialization::U’ |incomplete type
||‘boost::serialization::U’
--- Comment #12 from Patrick Palka ---
(In reply to Andrew Pinski from comment #11)
> (In reply to ensadc from comment #4)
> > Further reduced:
> >
> > template < int > struct b { };
> > template < typename n > struct g {
> > typedef b< sizeof(n) > l;
> > };
> > template < typename h, typename = typename g< h >::l > class aa {};
> > template < typename h, typename bz >
> > void bj(aa< h, bz >, int);
> > template < template < class > class ct > void bj(ct< class U >);
> > void f() {
> > bj(aa(), 0);
> > }
> >
>
> Hmm, it comes with -std=c++11 and -std=c++14 but not -std=c++17.
Started to be rejected (with -std=c++17) since the introduction of
-fnew-ttp-matching r7-5537-g31bfc9b9dd65ec
[Bug c++/109323] No error when neither of return_value or return_void is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323 --- Comment #3 from Enrico Maria De Angelis --- However, I'm not entirely sure (not anymore now that I've read the standard more carefully) that not having any of those two memebrs is an error.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #31 from Jakub Jelinek --- If the important side-effect is allocation of some GC memory, then perhaps (assuming you also see just 5 initialize_cfun calls with 2xint, TFmode float, uint and bool) testing hack might be: --- a/gcc/tree-inline.cc +++ b/gcc/tree-inline.cc @@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl, profile_count count) /* Get clean struct function. */ push_struct_function (new_fndecl, true); targetm.target_option.relayout_function (new_fndecl); + if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl +gen_raw_REG (GET_MODE (TYPE_MODE (DECL_RESULT (new_fndecl))), 8); /* We will rebuild these, so just sanity check that they are empty. */ gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL); If that would help, then it is just bad luck and bug somewhere else than here.
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #41 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:429a7a88438cc80e7c58d9f63d44838089899b12 commit r13-6945-g429a7a88438cc80e7c58d9f63d44838089899b12 Author: Andrew MacLeod Date: Tue Mar 28 12:16:34 2023 -0400 Add recursive GORI recompuations with a depth limit. PR tree-optimization/109154 gcc/ * gimple-range-gori.cc (gori_compute::may_recompute_p): Add depth limit. * gimple-range-gori.h (may_recompute_p): Add depth param. * params.opt (ranger-recompute-depth): New param. gcc/testsuite/ * gcc.dg/Walloca-13.c: Remove bogus warning that is now fixed.
[Bug target/109068] bpf: "error: too many function arguments for eBPF" for always_inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109068 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-03-30 Status|UNCONFIRMED |NEW Keywords||diagnostic --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/109279] RISC-V: complex constants synthesized should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #14 from Vineet Gupta ---
(In reply to Andrew Pinski from comment #12)
> Here is something to look into:
> #define const1 0x0101010101010101ULL
> #define const0 const1
> unsigned long long f(unsigned long long occ, const unsigned int sq) {
> unsigned long long t= (const0)>>32<<32 ;
> unsigned long long t1= (unsigned int)(const0) ;
> asm("":"+r"(t));
> return t | t1;
> }
Before commit 2e886eef7f2
li a5,16842752
addia5,a5,257
sllia0,a5,32
or a0,a0,a5
ret
With commit 2e886eef7f2
li a0,16842752
addia0,a0,257
mv a5,a0
sllia0,a0,32
or a0,a0,a5
ret
With commit 2e886eef7f2 + in_splitter check removed from riscv_move_integer()
li a0,16842752
li a5,16842752
addia5,a5,257
addia0,a0,257
sllia0,a0,32
or a0,a0,a5
ret
[Bug middle-end/109347] New: [lra] Spill failure for architecture without CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
Bug ID: 109347
Summary: [lra] Spill failure for architecture without CC
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: piggynl at outlook dot com
Target Milestone: ---
Created attachment 54791
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54791&action=edit
Reproduce for riscv64
For all architectures without condition code, when all registers are in use,
gcc fails to perform a spill.
mips64 and riscv64 are failing with certain code.
For example, the codes for mips64 and riscv64 reproducing the bug are in
attachments.
The expected behavior is generating a spill asm sequence before the `if` block
and a restore sequence after, so it will be a free register in the `if` block.
gcc is failing an assertion error with the examples. With a release build, gcc
falls into an infinity loop.
The assertion fails in lra.c:
if (e->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
{
/* We already made the edge no-critical in ira.c::ira */
lra_assert (!EDGE_CRITICAL_P (e));
^^
rtx_insn *tmp = BB_HEAD (e->dest);
if (LABEL_P (tmp))
The assertion was introduced in e3b3b59683c1.
[Bug fortran/109348] New: Pointer initialization fails for target with references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109348 Bug ID: 109348 Summary: Pointer initialization fails for target with references Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- As posted by Peter Klausler on clf complex, save, target :: a(4) = [(1.,0.),(2.,0.),(3.,0.),(4.,0)] real, pointer :: p(:) => a(1:3:2)%re print *, p end gfc doesn't even attempt to initialise the pointer. Malcolm Cohen and Steve Lionel both agree that this is valid F2018. complex, save, target :: a(4) = [(1.,0.),(2.,0.),(3.,0.),(4.,0)] real, pointer :: p(:) p(1:) => a(1:3:2)%re print *, p end Works, as long as an lbound is provided on the lhs. nagfor behaves similarly, whereas ifort does not even accept this version. Cheers Paul
[Bug middle-end/109347] [lra] Spill failure for architecture without CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347 --- Comment #1 from Piggy NL --- Created attachment 54792 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54792&action=edit Reproduce for mips64
[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
--- Comment #9 from Steve Kargl ---
On Wed, Mar 29, 2023 at 07:42:08PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
>
> --- Comment #3 from Steve Kargl ---
> On Wed, Mar 29, 2023 at 05:50:05PM +, emr-gnu at hev dot psu.edu wrote:
> >
> >
> > Extending my original demonstrator, if you add a "INTEGER(KIND=C_INT64_T) ::
> > E", you get the following output:
> >
> > > gfortran -m32 -fc-prototypes -fsyntax-only foo.f90
> >
> > long a;
> > {...}
> > long_long e;
> > } bar;
>
> The companion C processor is gcc. It is generating
> prototypes for that C processor. If one is manipulating
> the environment with a command line option such as -m32
> or -m64, then one likely needs to use the same option
> with gcc. Does 'gcc -m32' support "long_long"? If it
> doesn't, then you'll need to hack on
>
> gcc/fortran/dump-parse-tree.cc
> gcc/fortran/iso-c-binding.def
> gcc/fortran/trans-types.cc
If one instruments, write_decl() in dump-parse-tree.cc to
dump the table of bind(c) types, one can see why you get
what you get.
% cat a.f90
module foo
use, intrinsic :: iso_c_binding
implicit none
public :: bar
type, bind(c) :: bar
integer(c_int64_t) a
end type
end module
% gfcx -fc-prototypes -fsyntax-only a.f90 | grep "value=8 IN"
2 value=8 INTEGER c_long
3 value=8 INTEGER c_long_long
4 value=8 INTEGER c_intmax_t
5 value=8 INTEGER c_intptr_t
6 value=8 INTEGER c_ptrdiff_t
7 value=8 INTEGER c_size_t
12 value=8 INTEGER c_int64_t
17 value=8 INTEGER c_int_least64_t
22 value=8 INTEGER c_int_fast64_t
typedef struct bar {
long a;
} bar;
The for-loop in write_decl() breaks on the first match to
to both value=8 and INTEGER. It never reaches the 12th
table entry for c_int64_t.
[Bug fortran/84779] [10/11/12/13 Regression] Compiling gfortran.fortran-torture/execute/entry_4.f90 with -O1 or -Os and -fdefault-integer-8 gives an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779 anlauf at gcc dot gnu.org changed: What|Removed |Added CC|anlauf at gmx dot de |anlauf at gcc dot gnu.org --- Comment #13 from anlauf at gcc dot gnu.org --- I've come back to this PR again and spent a while trying to further narrow things down and to find the gcc options that make the code compile or fail. Minimal reproducer: complex function f2 (a) implicit none integer a logical e2 entry e2 (a) if (a > 0) then e2 = .true. else f2 = 45 endif end Basic command line: "gfortran -fdefault-integer-8", plus: these all lead to an ICE: ! -O1 ! -O1 -fno-tree-pre ! -O2 -fno-tree-pre but no ICE with: ! -O2 ! -O1 -ftree-pre ! -O2 -ftree-pre ! -O1 -fno-tree-sra ! -O2 -fno-tree-sra ! -O1 -fno-tree-sra -fno-tree-pre ! -O2 -fno-tree-sra -fno-tree-pre So is this now a frontend bug - what could it be? - or a middle-end issue?
[Bug middle-end/109128] [Offload][OpenMP][OpenACC] Static linking with unused offload function will lead to mismatch number of offload fn/symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128
--- Comment #4 from Tobias Burnus ---
Minor observations (unrelated to this bug but should be fixed. separately or
together):
- '@' file in lto-wrapper.cc's compile_offload_image's fork_execute call is
always the same. (Matters if there is more than one offloading target
configured)
- The sections ".gnu.offload_funcs" and ".gnu.offload_vars" are 'wx' but they
could be 'x' (i.e. read only as the function addresses do not need to be
written to). → TREE_READONLY (funcs_decl) = 1; (same for 'vars_decl').
* * *
Tried the following, but it did not help – 'ld' does not import any symbol from
the 'libone.a' library – neither before nor after the patch; not did
-no-as-needed help and -Wl,--print-gc-sections does not show any discarded
sections.
diff --git a/gcc/omp-offload.cc b/gcc/omp-offload.cc
index 3bd144e9ccf..e1b22729994 100644
--- a/gcc/omp-offload.cc
+++ b/gcc/omp-offload.cc
@@ -437,0 +438,13 @@ omp_finish_file (void)
+ TREE_READONLY (funcs_decl) = 1;
+ TREE_READONLY (vars_decl) = 1;
+#ifndef ACCEL_COMPILER
+ if (SUPPORTS_SHF_GNU_RETAIN)
+ {
+ DECL_ATTRIBUTES (funcs_decl) = tree_cons (get_identifier ("retain"),
+ NULL_TREE, NULL_TREE);
+ DECL_ATTRIBUTES (vars_decl) = tree_cons (get_identifier ("retain"),
+ NULL_TREE, NULL_TREE);
+ }
+ else
+ sorry ("support for % required for offloading");
+#endif
diff --git a/libgcc/offloadstuff.c b/libgcc/offloadstuff.c
index 4e1c4d41dd5..59e191c5e19 100644
--- a/libgcc/offloadstuff.c
+++ b/libgcc/offloadstuff.c
@@ -51 +51 @@ const void *const __offload_func_table[0]
- __attribute__ ((__used__, visibility ("hidden"),
+ __attribute__ ((__used__, visibility ("hidden"), retain,
@@ -54 +54 @@ const void *const __offload_var_table[0]
- __attribute__ ((__used__, visibility ("hidden"),
+ __attribute__ ((__used__, visibility ("hidden"), retain,
@@ -60 +60 @@ const void *const __offload_funcs_end[0]
- __attribute__ ((__used__, visibility ("hidden"),
+ __attribute__ ((__used__, visibility ("hidden"), retrain,
@@ -63 +63 @@ const void *const __offload_vars_end[0]
- __attribute__ ((__used__, visibility ("hidden"),
+ __attribute__ ((__used__, visibility ("hidden"), retrain,
* * *
What's interesting is the file -foffload-objects=a.ofldlist - produced by
lto-plugin:
* If there is a common block in 'one.f90' (and via module use also in
'two.f90'), the a.ofldlist file contains both 'two.o' and the ./libone.a@0xc0
library.
* But if there is no common block in 'one.f90' (and hence also not in
'two.f90'), the a.ofldlist file contains only 'two.o'.
[Bug fortran/109348] Pointer initialization fails for target with references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109348 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||anlauf at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from anlauf at gcc dot gnu.org --- Reported already in pr109171. *** This bug has been marked as a duplicate of bug 109171 ***
