[Bug bootstrap/97933] [11 Regression] Bootstrap failure on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |11.0
[Bug bootstrap/97933] [11 Regression] Bootstrap failure on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933 --- Comment #2 from Jakub Jelinek --- Created attachment 49610 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49610&action=edit ipa-sra.ii.xz unxz ipa-sra.ii.xz ./cc1plus -quiet -fno-PIE -O2 -fno-checking -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -march=zEC12 -mtune=z13 -mlong-double-128 ipa-sra.ii with cc1plus with that reload change reverted vs. with that change in results in: --- ipa-sra.s1 2020-11-22 10:51:59.367579654 +0100 +++ ipa-sra.s2 2020-11-22 10:52:07.166491603 +0100 @@ -4686,13 +4686,13 @@ _ZN26ipa_sra_function_summaries9duplicat .cfi_offset 15, -40 lay %r15,-176(%r15) .cfi_def_cfa_offset 336 - stg %r6,168(%r15) + stg %r6,160(%r15) risbgn %r1,%r1,64-1,128+63,2+1 risbgn %r2,%r1,58,58+1-1,64-58-1 stc %r2,8(%r6) tm 8(%r5),16 jne .L1172 - lg %r1,168(%r15) + lg %r1,160(%r15) lgr %r13,%r5 ni 8(%r1),239 ltg %r8,0(%r5) @@ -4728,10 +4728,10 @@ _ZN26ipa_sra_function_summaries9duplicat slrk%r2,%r12,%r1 jnhe.L1129 .L1135: - st %r12,164(%r15) + st %r12,172(%r15) ltr %r12,%r12 lhi %r1,1 - stoce %r1,164(%r15) + stoce %r1,172(%r15) lghi%r6,0 .L1130: llgfr %r2,%r6 @@ -4801,7 +4801,7 @@ _ZN26ipa_sra_function_summaries9duplicat stg %r2,8(%r1,%r3) brct%r11,.L1160 .L1136: - l %r1,164(%r15) + l %r1,172(%r15) aghi%r6,1 brct%r1,.L1158 lmg %r6,%r15,224(%r15) @@ -4823,8 +4823,7 @@ _ZN26ipa_sra_function_summaries9duplicat lg %r1,8(%r9,%r8) j .L1139 .L1158: - st %r1,164(%r15) - lg %r1,168(%r15) + lg %r1,160(%r15) lg %r8,0(%r13) lg %r7,0(%r1) j .L1130 @@ -4855,7 +4854,7 @@ _ZN26ipa_sra_function_summaries9duplicat brctg %r3,.L1131 j .L1134 .L1127: - lg %r11,168(%r15) + lg %r11,160(%r15) lghi%r4,1 lgr %r2,%r11 llgfr %r3,%r12 difference and sadly the ipa-sra.s2 variant crashes.
[Bug c/44511] Misdetects missing return with non-void return type, but only if the function is static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44511 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- PR97793 has some more info on this.
[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936 --- Comment #2 from H.J. Lu --- Also 30_threads/semaphore/try_acquire_until.cc.
[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936
--- Comment #3 from H.J. Lu ---
(gdb) bt
#0 0x7f6b5984330d in syscall () from /lib64/libc.so.6
#1 0x00401429 in std::__detail::__platform_wait (
__addr=__addr@entry=0x7ffc848e7014, __val=__val@entry=1)
at
/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_wait.h:99
#2 0x0040150b in std::__atomic_wait::wait(int, std::memory_order) const::{lambda()#1}>(int
const*, int, std::__atomic_base::wait(int, std::memory_order)
const::{lambda()#1}) (
__addr=__addr@entry=0x7ffc848e7014, __old=__old@entry=1, __pred=...)
at
/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_wait.h:276
#3 0x00401788 in std::__atomic_base::wait (
__m=std::memory_order::seq_cst, __old=1, this=0x7ffc848e7014)
at
/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_base.h:607
#4 test02 ()
at
/export/gnu/import/git/gcc-test-master-intel64-native/src-master/libstdc++-v3/testsuite/30_threads/semaphore/try_acquire_until.cc:87
#5 0x004012c2 in main ()
at
/export/gnu/import/git/gcc-test-master-intel64-native/src-master/libstdc++-v3/testsuite/30_threads/semaphore/try_acquire_until.cc:93
(gdb)
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 Thomas Koenig changed: What|Removed |Added Status|NEW |WAITING --- Comment #18 from Thomas Koenig --- Hi Toon, with https://gcc.gnu.org/pipermail/gcc-cvs/2020-November/337586.html , your program seems to work (at least the values look reasonable): Decomposition information on image 2 : there are 3 * 2 slabs; the slabs are 24 * 35 grid cells in size. Decomposition information on image 5 : there are 3 * 2 slabs; the slabs are 24 * 35 grid cells in size. Decomposition information on image 3 : there are 3 * 2 slabs; the slabs are 24 * 35 grid cells in size. Decomposition information on image 1 : there are 3 * 2 slabs; the slabs are 24 * 35 grid cells in size. Decomposition information on image 4 : there are 3 * 2 slabs; the slabs are 24 * 35 grid cells in size. Decomposition information on image 6 : there are 3 * 2 slabs; the slabs are 24 * 35 grid cells in size. Time 0 Image 5 PS= 99978.4531 T=300.364166 U=19.3067131 V=15.9685030 W= 0.138491884 Q= 2.17480748E-03 Time 0 Image 1 PS= 99985.0938 T=300.027161 U= -9.06420994 V=5.92245483 W= 0.137841657 Q= 2.10389541E-03 Time 0 Image 3 PS= 9.3828 T=300.014618 U= -4.48150349 V= -1.37469864 W= -8.73371959E-02 Q= 1.81287562E-03 Time 0 Image 2 PS= 99986.4141 T=300.200836 U= -3.47342205 V=16.5930214 W= 0.205771178 Q= 1.97321200E-03 Time 0 Image 6 PS= 99980.4141 T=300.424133 U=12.8092175 V=11.5236654 W=6.01452552E-02 Q= 1.87643641E-03 Time 0 Image 4 PS= 100010.516 T=300.005005 U=11.4250631 V=3.44926071 W= -0.227272436 Q= 2.07653991E-03 Time 240 Image 6 PS= 0.5781 T=300.666931 U=22.8395500 V= -11.9721365 W=3.66642363E-02 Q= 1.70292379E-03 Time 240 Image 2 PS= 99980.1484 T=300.538757 U=19.1216316 V=34.7150421 W=3.16514075E-03 Q= 2.09417334E-03 Time 240 Image 1 PS= 99969.6641 T=300.400970 U=3.65581894 V=16.8670387 W=2.10290849E-02 Q= 2.06003617E-03 Time 240 Image 3 PS= 5.2734 T=300.354370 U=4.84142876 V=4.59838200 W=1.12933442E-02 Q= 1.67453510E-03 Time 240 Image 5 PS= 99959.9141 T=300.308228 U=35.2094879 V=26.3194275 W=6.13999888E-02 Q= 2.24495190E-03 Time 240 Image 4 PS= 100024.211 T=300.642700 U= -21.4838848 V= -5.71874714 W= 0.123860441 Q= 1.77718676E-03 Time 480 Image 1 PS= 99988.9688 T=300.262726 U= -1.2006 V=13.3446560 W= -1.83758438E-02 Q= 1.98666588E-03 Time 480 Image 5 PS= 100030.500 T=300.034546 U=8.11599827 V=49.5809326 W= -1.16332620E-02 Q= 2.18066899E-03 Time 480 Image 3 PS= 99974.3828 T=300.171265 U= -12.1284695 V=13.2599001 W= -0.132261544 Q= 1.64680334E-03 Time 480 Image 6 PS= 99983.6328 T=299.253204 U= -16.0964108 V= -7.74500656 W= -0.392248750 Q= 1.88040221E-03 Time 480 Image 2 PS= 99969.3672 T=299.095215 U= -5.18578625 V=36.8412170 W= -0.231359661 Q= 1.97951938E-03 Time 480 Image 4 PS= 100016.453 T=300.540619 U= -1.72649384 V=38.7740860 W= -0.185899958 Q= 2.31738412E-03 Thanks again for the test case, it certainly showed up a lot of bugs :-)
[Bug ipa/97937] New: Line numbers are missing from duplicated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97937
Bug ID: 97937
Summary: Line numbers are missing from duplicated function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Consider this test case:
$ cat test.c
int test(void)
{
return 0;
}
int test1(void)
{
return 0;
}
struct s {
int (*x) (void);
int (*y) (void);
};
struct s xxx = { test, test1 };
$ gcc -g -O2 -S test.c
test.s:
.file "test.c"
.text
.Ltext0:
.p2align 4
.globl test
.type test, @function
test:
.LFB0:
.file 1 "test.c"
.loc 1 2 1 view -0
.cfi_startproc
.loc 1 3 3 view .LVU1
.loc 1 4 1 is_stmt 0 view .LVU2
xorl%eax, %eax
ret
.cfi_endproc
.LFE0:
.size test, .-test
.p2align 4
.globl test1
.type test1, @function
test1:
.LFB3:
.cfi_startproc
xorl%eax, %eax
ret
.cfi_endproc
The problem is that there are no line numbers in test1.
That is caused by this statement in symtab-thunks.cc
428 if (force_gimple_thunk)
429 DECL_IGNORED_P (thunk_fndecl) = 1;
#0 expand_thunk (node=0x7fffeee7edd0, output_asm_thunks=false,
force_gimple_thunk=true)
at ../../gcc-trunk/gcc/symtab-thunks.cc:429
#1 0x00fca17b in cgraph_node::create_wrapper (this=0x7fffeee7edd0,
target=0x7fffeee7ebb0)
at ../../gcc-trunk/gcc/cgraphunit.c:2601
#2 0x0281d7bd in ipa_icf::sem_function::merge (this=0x46dfc90,
alias_item=0x46c2880)
at ../../gcc-trunk/gcc/ipa-icf.c:1299
#3 0x02825672 in ipa_icf::sem_item_optimizer::merge_classes
(this=0x4746390, prev_class_count=902,
loaded_symbols=74) at ../../gcc-trunk/gcc/ipa-icf.c:3406
#4 0x028220c8 in ipa_icf::sem_item_optimizer::execute (this=0x4746390)
at ../../gcc-trunk/gcc/ipa-icf.c:2459
together with this in final.c:
2433case NOTE_INSN_BEGIN_STMT:
2434 gcc_checking_assert (cfun->debug_nonbind_markers);
2435 if (!DECL_IGNORED_P (current_function_decl)
2436 && notice_source_line (insn, NULL))
(gdb)
2437{
2438output_source_line:
2439 (*debug_hooks->source_line) (last_linenum,
last_columnnum,
2440 last_filename,
last_discriminator,
2441 true);
2442 clear_next_view_needed (seen);
2443}
2444 break;
which prevents the line number from being included in the asm.
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #19 from Toon Moene --- Thanks. It works now for export GFORTRAN_NUM_IMAGES=1..10 for me. Unfortunately, when I want to change the nxglobal and nyglobal values in the domain via the namelist, sometimes the "default" values are used. However, this could well be because I do not do the distribution of the configuration values to the images other than 1 correctly. If you see any shortcoming here I would be very interested in the analysis. In any way, you can use this test case as you see fit - I wrote this in 2018 specifically to test the native coarrays ...
[Bug tree-optimization/95853] Failure to optimize add overflow pattern to __builtin_add_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95853 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c1fb592f2c3c6b5a6616cf882ce24d30e167a646 commit r11-5238-gc1fb592f2c3c6b5a6616cf882ce24d30e167a646 Author: Jakub Jelinek Date: Sun Nov 22 19:16:34 2020 +0100 widening_mul: pattern recognize further forms of __builtin_add_overflow [PR95853] The following patch recognizes some further forms of additions with overflow checks as shown in the testcase, in particular where the unsigned addition is performed in a wider mode just to catch overflow with a > narrower_utype_max check. 2020-11-22 Jakub Jelinek PR tree-optimization/95853 * tree-ssa-math-opts.c (uaddsub_overflow_check_p): Add maxval argument, if non-NULL, instead look for r > maxval or r <= maxval comparisons. (match_uaddsub_overflow): Pattern recognize even other forms of __builtin_add_overflow, in particular when addition is performed in a wider type and result compared to maximum of the narrower type. * gcc.dg/pr95853.c: New test.
[Bug d/97889] d: OutOfMemoryError thrown when appending to an array with a side effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97889 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:23045f8b062e20672f5170fc66532de7a5d9a1d6 commit r11-5239-g23045f8b062e20672f5170fc66532de7a5d9a1d6 Author: Iain Buclaw Date: Sun Nov 22 14:29:54 2020 +0100 d: Fix OutOfMemoryError thrown when appending to an array with a side effect When appending a character to an array, the result of that concat assignment was not the new value of the array, similarly, when appending an array to another array, side effects were evaluated in reverse to the expected order of evaluation. As of this change, the address of the left-hand side expression is saved and re-used as the result. Its evaluation is now also forced to occur before the concat operation itself is called. gcc/d/ChangeLog: PR d/97889 * expr.cc (ExprVisitor::visit (CatAssignExp *)): Enforce LTR order of evaluation on left and right hand side expressions. gcc/testsuite/ChangeLog: PR d/97889 * gdc.dg/torture/pr97889.d: New test.
[Bug d/97889] d: OutOfMemoryError thrown when appending to an array with a side effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97889 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:0209b0ead2617d9226ef53d4fc4756d11dd6ea59 commit r10-9061-g0209b0ead2617d9226ef53d4fc4756d11dd6ea59 Author: Iain Buclaw Date: Sun Nov 22 14:29:54 2020 +0100 d: Fix OutOfMemoryError thrown when appending to an array with a side effect When appending a character to an array, the result of that concat assignment was not the new value of the array, similarly, when appending an array to another array, side effects were evaluated in reverse to the expected order of evaluation. As of this change, the address of the left-hand side expression is saved and re-used as the result. Its evaluation is now also forced to occur before the concat operation itself is called. gcc/d/ChangeLog: PR d/97889 * expr.cc (ExprVisitor::visit (CatAssignExp *)): Enforce LTR order of evaluation on left and right hand side expressions. gcc/testsuite/ChangeLog: PR d/97889 * gdc.dg/pr97889.d: New test. (cherry picked from commit 23045f8b062e20672f5170fc66532de7a5d9a1d6)
[Bug d/97889] d: OutOfMemoryError thrown when appending to an array with a side effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97889 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Buclaw --- Fixed and backported.
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #20 from Toon Moene --- Example of the problem described in the last comment: (export LD_LIBRARY_PATH=/home/toon/compilers/install/coarray_native/lib/gcc/x86_64-pc-linux-gnu/11.0.0; export GFORTRAN_NUM_IMAGES=28; echo ' &config nxglobal=936, nyglobal=770, nzglobal=60 / ' | ./a.out) Decomposition information on image 1 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 6 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 9 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 24 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 23 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 2 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 22 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 16 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 21 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 12 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 8 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 26 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 14 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 5 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 15 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 3 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 19 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 27 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 10 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 7 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 25 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 11 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 4 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 13 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 20 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 17 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 18 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 28 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Size mismatch for coarray allocation id 0x419400: found = 2882880 != size = 20160 Size mismatch for coarray allocation id 0x419400: found = 2882880 != size = 20160 ERROR: Image 28(0x1e0a22) failed BTW, I cannot replicate this reliably, so it is probably timing related ...
[Bug c++/97938] New: g++ crash when inferring type of auto parameter pack in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938
Bug ID: 97938
Summary: g++ crash when inferring type of auto parameter pack
in lambda capture
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: elel at 3wh dot net
Target Milestone: ---
The following test case:
#include
#include
template
int print_args(Args&&... args) {
std::cout << (args << ...);
return sizeof...(args);
}
template
auto fwd(const T1& t1, const T2& t2) {
return std::apply([&t2] (auto&&... ts1) {
return std::apply([...ts1 = std::forward(ts1)] (auto&&...
ts2) {
return print_args(ts1..., std::forward(ts2)...);
}, t2);
}, t1);
}
int main() {
auto t1 = std::make_tuple(int{1}, float{2});
auto t2 = std::make_tuple(float{3}, int{4});
return fwd(t1, t2);
}
Compiled as:
g++ -std=c++20 -g -O2 gcc_crash.cpp
Crashes g++ with the following message:
gcc_crash.cpp: In instantiation of ‘fwd,
std::tuple >:: [with auto:11 = {const int&,
const float&}]’:
/usr/include/c++/10.2.0/type_traits:2506:26: required by substitution of
‘template static std::__result_of_success()((declval<_Args>)()...)), std::__invoke_other>
std::__result_of_other_impl::_S_test(int) [with _Fn = fwd, std::tuple >::; _Args = {const int&,
const float&}]’
/usr/include/c++/10.2.0/type_traits:2517:55: required from ‘struct
std::__result_of_impl,
std::tuple >::, const int&, const float&>’
/usr/include/c++/10.2.0/type_traits:138:12: recursively required by
substitution of ‘template struct
std::__is_invocable_impl<_Result, _Ret, true, std::__void_t > [with _Result = std::__invoke_result,
std::tuple >::, const int&, const float&>;
_Ret = void]’
/usr/include/c++/10.2.0/type_traits:138:12: required from ‘struct
std::__and_, std::tuple >::, const int&, const
float&>, void, true, void>,
std::__call_is_nothrow,
std::tuple >::, const int&, const float&>,
fwd, std::tuple >::,
const int&, const float&> >’
/usr/include/c++/10.2.0/type_traits:2979:12: required from ‘struct
std::is_nothrow_invocable, std::tuple
>::, const int&, const float&>’
/usr/include/c++/10.2.0/tuple:1715:37: required from ‘constexpr const bool
std::__unpack_std_tuple struct
std::is_nothrow_invocable, fwd, std::tuple
>::, const std::tuple&>’
/usr/include/c++/10.2.0/tuple:1730:14: required from ‘constexpr
decltype(auto) std::apply(_Fn&&, _Tuple&&) [with _Fn = fwd, std::tuple >::; _Tuple = const
std::tuple&]’
gcc_crash.cpp:12:20: required from ‘auto fwd(const T1&, const T2&) [with T1 =
std::tuple; T2 = std::tuple]’
gcc_crash.cpp:22:20: required from here
gcc_crash.cpp:13:23: internal compiler error: Segmentation fault
13 | return std::apply([...ts1 = std::forward(ts1)]
(auto&&... ts2) {
|
^
14 | return print_args(ts1..., std::forward(ts2)...);
| ~~~
15 | }, t2);
| ~
Please submit a full bug report,
with preprocessed source if appropriate.
In other scenarios (not the minimal test case above) the same bug triggers the
message:
internal compiler error: in cxx_incomplete_type_diagnostic, at cp/typeck2.c:584
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW --- Comment #21 from Thomas Koenig --- Hi Toon, yes, I can replicate this.
[Bug c/44511] Misdetects missing return with non-void return type, but only if the function is static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44511 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97793 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-11-22 Status|UNCONFIRMED |NEW --- Comment #6 from Eric Gallager --- (In reply to eggert from comment #4) > We recently ran into this bug in Gnulib, and this affects downstream GNU > test programs with threads that never return, because POSIX thread functions > return 'void *'. For example, with GNU grep 3.6, './configure > --enable-gcc-warnings; make' fails to build; see: > > https://bugs.gnu.org/44535 > > I worked around the problem by adding '#pragma GCC diagnostic ignored > "-Wreturn-type"' to the Gnulib test module in question. It would be nice if > such a workaround weren't needed. Taking this as confirmation.
[Bug target/97939] New: ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
Bug ID: 97939
Summary: ICE on sparc64 with UBsan for "i + 4096" on long:
unrecognizable insn during RTL pass: vregs
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
On the following code:
long f (long i)
{
return i + 4096;
}
I get:
vinc17@gcc202:~$ gcc -fsanitize=undefined -c tst.c
tst.c: In function ‘f’:
tst.c:4:1: error: unrecognizable insn:
4 | }
| ^
(insn 7 6 8 2 (parallel [
(set (reg:CCXV 100 %icc)
(compare:CCXV (plus:DI (reg:DI 113)
(const_int 4096 [0x1000]))
(unspec:DI [
(reg:DI 113)
(const_int 4096 [0x1000])
] UNSPEC_ADDV)))
(set (reg:DI 112)
(plus:DI (reg:DI 113)
(const_int 4096 [0x1000])))
]) "tst.c":3:12 -1
(nil))
during RTL pass: vregs
tst.c:4:1: internal compiler error: in extract_insn, at recog.c:2294
0xfff8000100e72803 __libc_start_main
./csu/libc-start.c:308
I don't get any error on the following constants: 2048, 4095, 4097, 8192.
4096 seems special!
Note: I found this issue when trying to build GMP 6.2.1 with UBsan. The failure
occurs on extract-dbl.c at line
exp = (exp + 64 * GMP_NUMB_BITS) / GMP_NUMB_BITS - 64 * GMP_NUMB_BITS /
GMP_NUMB_BITS + 1;
due to the "exp + 64 * GMP_NUMB_BITS" with GMP_NUMB_BITS = 64.
[Bug target/97939] ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939 --- Comment #1 from Vincent Lefèvre --- I forgot: That's a Debian sid machine with Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc64-linux-gnu/10/lto-wrapper Target: sparc64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.0-17' --with -bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go ,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program -suffix=-10 --program-prefix=sparc64-linux-gnu- --enable-shared --enable-linker- build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug -- enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-o bject --disable-libquadmath --disable-libquadmath-support --enable-plugin --enab le-default-pie --with-system-zlib --disable-libphobos --enable-objc-gc=auto --en able-multiarch --disable-werror --with-cpu-32=ultrasparc --enable-targets=all -- with-long-double-128 --enable-multilib --enable-checking=release --build=sparc64-linux-gnu --host=sparc64-linux-gnu --target=sparc64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (Debian 10.2.0-17)
[Bug c++/97938] g++ crash when inferring type of auto parameter pack in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Last reconfirmed||2020-11-23 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/97938] 9/10/11 Regression] g++ crash when inferring type of auto parameter pack in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938 Marek Polacek changed: What|Removed |Added Summary|g++ crash when inferring|9/10/11 Regression] g++ |type of auto parameter pack |crash when inferring type |in lambda capture |of auto parameter pack in ||lambda capture Target Milestone|--- |9.4
[Bug target/97870] [11 Regression] ICE: verify_flow_info failed (error: too many outgoing branch edges from bb 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97870 --- Comment #4 from Arseny Solokha --- Fixed.
[Bug target/97940] New: [11 Regression] ICE: in extract_insn, at recog.c:2306 (error: impossible constraint in 'asm'; error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97940
Bug ID: 97940
Summary: [11 Regression] ICE: in extract_insn, at recog.c:2306
(error: impossible constraint in 'asm'; error:
unrecognizable insn)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc-11.0.0-alpha20201122 snapshot (g:e23f47ec4065e9eec53c4ad9db91bc36a4f90793)
ICEs when compiling gcc/testsuite/gcc.c-torture/compile/asmgoto-3.c w/
-mcpu=powerpc64le:
% powerpc-e300c3-linux-gnu-gcc-11.0.0 -mcpu=powerpc64le -c
gcc/testsuite/gcc.c-torture/compile/asmgoto-3.c
gcc/testsuite/gcc.c-torture/compile/asmgoto-3.c: In function 'foo5':
gcc/testsuite/gcc.c-torture/compile/asmgoto-3.c:60:3: error: impossible
constraint in 'asm'
60 | asm goto ("": "=a" (x), "=d" (y), "=c" (z), "=b" (v), "=S" (w) : : :
lab, lab2, lab3, lab4, lab5);
| ^~~
gcc/testsuite/gcc.c-torture/compile/asmgoto-3.c:71:1: error: unrecognizable
insn:
71 | }
| ^
(jump_insn 10 2 11 2 (parallel [
(set (reg:SI 119 [ x ])
(asm_operands:SI ("") ("=a") 0 []
[]
[
(label_ref:SI 11)
(label_ref:SI 42)
(label_ref:SI 47)
(label_ref:SI 52)
(label_ref:SI 57)
] gcc/testsuite/gcc.c-torture/compile/asmgoto-3.c:60))
(set (reg:SI 120 [ y ])
(asm_operands:SI ("") ("=d") 1 []
[]
[
(label_ref:SI 11)
(label_ref:SI 42)
(label_ref:SI 47)
(label_ref:SI 52)
(label_ref:SI 57)
] gcc/testsuite/gcc.c-torture/compile/asmgoto-3.c:60))
(set (reg:SI 121 [ z ])
(asm_operands:SI ("") ("=c") 2 []
[]
[
(label_ref:SI 11)
(label_ref:SI 42)
(label_ref:SI 47)
(label_ref:SI 52)
(label_ref:SI 57)
] gcc/testsuite/gcc.c-torture/compile/asmgoto-3.c:60))
(set (reg:SI 122 [ v ])
(asm_operands:SI ("") ("=b") 3 []
[]
[
(label_ref:SI 11)
(label_ref:SI 42)
(label_ref:SI 47)
(label_ref:SI 52)
(label_ref:SI 57)
] gcc/testsuite/gcc.c-torture/compile/asmgoto-3.c:60))
(set (reg:SI 123 [ w ])
(asm_operands:SI ("") ("=S") 4 []
[]
[
(label_ref:SI 11)
(label_ref:SI 42)
(label_ref:SI 47)
(label_ref:SI 52)
(label_ref:SI 57)
] gcc/testsuite/gcc.c-torture/compile/asmgoto-3.c:60))
(clobber (reg:SI 98 ca))
]) "gcc/testsuite/gcc.c-torture/compile/asmgoto-3.c":60:3 -1
(insn_list:REG_LABEL_TARGET 11 (insn_list:REG_LABEL_TARGET 42
(insn_list:REG_LABEL_TARGET 47 (insn_list:REG_LABEL_TARGET 52 (nil)
-> 57)
during RTL pass: ira
gcc/testsuite/gcc.c-torture/compile/asmgoto-3.c:71:1: internal compiler error:
in extract_insn, at recog.c:2306
0x67ed88 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/rtl-error.c:108
0x67eda8 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/rtl-error.c:116
0x67d4a4 extract_insn(rtx_insn*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/recog.c:2306
0xbff072 ira
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/ira.c:5423
0xbff072 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/ira.c:5945
[Bug target/97870] [11 Regression] ICE: verify_flow_info failed (error: too many outgoing branch edges from bb 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97870 Arseny Solokha changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Arseny Solokha --- .
[Bug sanitizer/97941] New: [HWASAN] use After free not working as per expectation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941
Bug ID: 97941
Summary: [HWASAN] use After free not working as per expectation
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Hello Matthew
While HWASAN verification feature, Source I taken from GCC11 trunk.
I observed Some HWASAN features are not working as per expectation.
Like use After free, Is this known behaviors/Issue ?
int main() {
char *x = (char*)malloc(10 * sizeof(char*));
free(x);
return x[5];
}
./myhak
HWAddressSanitizer:DEADLYSIGNAL
==1227==ERROR: HWAddressSanitizer: SEGV on unknown address 0x0030 (pc
0x004096c8 bp 0x005f00ae9fe0 sp 0x005f00ae8d10 T1227)
==1227==The signal is caused by a UNKNOWN memory access.
==1227==Hint: address points to the zero page.
#0 0x4096c8 in GetAccessInfo
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:383
#1 0x4096c8 in HwasanOnSIGTRAP
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:445
#2 0x4096c8 in __hwasan::HwasanOnDeadlySignal(int, void*, void*)
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:470
#3 0x5f00ae9fec ()
#4 0x406918 in __hwasan_load1
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan.cpp:446
#5 0x43815c in main
(/data10/1000/akhilesh.k/Activity/buildroot/myhak+0x43815c)
#6 0x55009830a0 in __libc_start_main ../csu/libc-start.c:308
#7 0x4023c4 (/data10/1000/akhilesh.k/Activity/buildroot/myhak+0x4023c4)
HWAddressSanitizer can not provide additional info.
SUMMARY: HWAddressSanitizer: SEGV
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:383
in GetAccessInfo
==1227==ABORTING
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #43 from Levy ---
Thanks for pointing the hook out Jim.
for both patched and unpatched, so far I've been traced through
try_replace_in_use()
to
reload_combine_recognize_const_pattern()
to
reload_combine()
to
reload_cse_regs()
to
pass_postreload_cse::execute()
in postreload.c
---
For reload_combine(), by printing each insn at front of the loop: (line 1302)
for (insn = get_last_insn (); insn; insn = prev)
{
debug_rtx(insn)
...
}
---
Unpatched gcc shows:
(insn 13 11 14 2 (set (reg:DI 10 a0)
(sign_extend:DI (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 44 [0x2c])) [1 MEM[(int *)array_5(D) + 812B]+0
S4 A32]))) "array_test.c":9:5 90 {extendsidi2}
(nil))
(insn 11 10 13 2 (set (reg:SI 14 a4 [83])
(plus:SI (reg:SI 14 a4 [orig:84 MEM[(int *)array_5(D) + 808B] ] [84])
(reg:SI 10 a0 [80]))) "array_test.c":8:5 3 {addsi3}
(nil))
(insn 10 8 11 2 (set (reg:DI 14 a4)
(sign_extend:DI (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 40 [0x28])) [1 MEM[(int *)array_5(D) + 808B]+0
S4 A32]))) "array_test.c":8:5 90 {extendsidi2}
(expr_list:REG_EQUIV (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 40 [0x28])) [1 MEM[(int *)array_5(D) + 808B]+0 S4
A32])
(nil)))
(insn 8 7 10 2 (set (reg:SI 10 a0 [80])
(plus:SI (reg:SI 10 a0 [orig:81 MEM[(int *)array_5(D) + 800B] ] [81])
(reg:SI 14 a4 [orig:82 MEM[(int *)array_5(D) + 804B] ] [82])))
"array_test.c":7:5 3 {addsi3}
(nil))
(insn 7 6 8 2 (set (reg:DI 14 a4)
(sign_extend:DI (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 36 [0x24])) [1 MEM[(int *)array_5(D) + 804B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(expr_list:REG_EQUIV (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 36 [0x24])) [1 MEM[(int *)array_5(D) + 804B]+0 S4
A32])
(nil)))
(insn 6 23 7 2 (set (reg:DI 10 a0)
(sign_extend:DI (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 32 [0x20])) [1 MEM[(int *)array_5(D) + 800B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(expr_list:REG_EQUIV (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 32 [0x20])) [1 MEM[(int *)array_5(D) + 800B]+0 S4
A32])
(nil)))
---
Patched one shows already merged results:
(insn 16 14 18 2 (set (reg:DI 10 a0 [orig:90 MEM[(int *)array_5(D) + 812B] ]
[90])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 10 a0 [96])
(const_int 812 [0x32c])) [1 MEM[(int *)array_5(D) + 812B]+0
S4 A32]))) "array_test.c":9:5 90 {extendsidi2}
(nil))
(insn 14 12 16 2 (set (reg:SI 15 a5 [85])
(plus:SI (reg:SI 15 a5 [80])
(reg:SI 14 a4 [orig:87 MEM[(int *)array_5(D) + 808B] ] [87])))
"array_test.c":8:5 3 {addsi3}
(nil))
(insn 12 10 14 2 (set (reg:DI 14 a4 [orig:87 MEM[(int *)array_5(D) + 808B] ]
[87])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 10 a0 [96])
(const_int 808 [0x328])) [1 MEM[(int *)array_5(D) + 808B]+0
S4 A32]))) "array_test.c":8:5 90 {extendsidi2}
(nil))
(insn 10 8 12 2 (set (reg:SI 15 a5 [80])
(plus:SI (reg:SI 15 a5 [orig:84 MEM[(int *)array_5(D) + 804B] ] [84])
(reg:SI 14 a4 [orig:82 MEM[(int *)array_5(D) + 800B] ] [82])))
"array_test.c":7:5 3 {addsi3}
(nil))
(insn 8 6 10 2 (set (reg:DI 15 a5 [orig:84 MEM[(int *)array_5(D) + 804B] ]
[84])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 10 a0 [96])
(const_int 804 [0x324])) [1 MEM[(int *)array_5(D) + 804B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(nil))
(insn 6 27 8 2 (set (reg:DI 14 a4 [orig:82 MEM[(int *)array_5(D) + 800B] ]
[82])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 10 a0 [96])
(const_int 800 [0x320])) [1 MEM[(int *)array_5(D) + 800B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(nil))
---
Before reload_combine () is reload_cse_regs_1() in reload_cse_regs() which
"detects no-op moves where we happened to assign two different pseudo-registers
to the same hard register"
and pass_postreload_cse::execute calls reload_cse_regs()
pass_postreload_cse::execute() look like the entry point for postreload.c
In order to confirm it's not in postreload.c, I put:
--
rtx_insn *insn, *next;
for (insn = get_insns (); insn; insn = next)
{
debug_rtx(insn);
next = NEXT_INSN (insn);
}
--
in pass_postreload_cse::execute (function *fun)
right after:
if (!dbg_cnt (postreload_cse))
return 0;
-
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #44 from Levy --- should_replace_address() in fwprop.c looks really interesting: /* OLD is a memory address. Return whether it is good to use NEW instead, for a memory access in the given MODE. */
[Bug middle-end/97931] missing -Wuninitialized initializing an aggregate member with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97931 Richard Biener changed: What|Removed |Added Version|unknown |11.0 --- Comment #1 from Richard Biener --- Probably because the FE emits a CONSTRUCTOR node were missing elements are implicitely zero in GENERIC semantics, unless CONSTRUCTOR_NO_CLEARING is set.
[Bug c/97932] [8/9/10/11 Regression] Preprocessor, generated error dumps most of the source file, not just one line by r6-5941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Version|unknown |11.0
[Bug ipa/97937] [11 Regression] Line numbers are missing from duplicated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97937 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |11.0 Keywords||wrong-debug Summary|Line numbers are missing|[11 Regression] Line |from duplicated function|numbers are missing from ||duplicated function --- Comment #1 from Richard Biener --- It doesn't look like a thunk anyway - we seem to inline the function back?! Guess this is a case where we shouldn't ICF because it only degrades things (as seen).
[Bug c++/97938] [9/10/11 Regression] g++ crash when inferring type of auto parameter pack in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938 Richard Biener changed: What|Removed |Added Summary|9/10/11 Regression] g++|[9/10/11 Regression] g++ |crash when inferring type |crash when inferring type |of auto parameter pack in |of auto parameter pack in |lambda capture |lambda capture Keywords||ice-on-valid-code Priority|P3 |P2
[Bug target/97940] [11 Regression] ICE: in extract_insn, at recog.c:2306 (error: impossible constraint in 'asm'; error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97940 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #45 from Levy --- Basically crossed out the rtlanal.c and fwprop.c I'm looking back at riscv.c. Since address_cost() was called by hook function new_address_profitable_p(), may be some place uses this function would provide more info
[Bug ipa/97937] [11 Regression] Line numbers are missing from duplicated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97937 Jan Hubicka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jan Hubicka --- There is old PR on this *** This bug has been marked as a duplicate of bug 63572 ***
[Bug debug/63572] [8/9/10/11 Regression] ICF breaks user debugging experience
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572 Jan Hubicka changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #24 from Jan Hubicka --- *** Bug 97937 has been marked as a duplicate of this bug. ***
