[Bug c/105100] [10/11/12 Regression] Strange warning when modifying structures "writing 1 byte into a region of size 0" when compile with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105100 Richard Biener changed: What|Removed |Added Summary|[10/11/12 RegressionStrange |[10/11/12 Regression] |warning when modifying |Strange warning when |structures "writing 1 byte |modifying structures |into a region of size 0"|"writing 1 byte into a |when compile with -O3 |region of size 0" when ||compile with -O3 Priority|P3 |P2 Target Milestone|--- |10.4 Known to work||9.4.0 --- Comment #2 from Richard Biener --- There might be a duplicate. It's the usual address CSE issue. -fno-code-hoisting avoids it in this case. [local count: 184361477]: - [t.c:23:12] pb_17 = [t.c:23:29] &[t.c:23:34] [t.c:23:34] MEM[(struct b_t *)dst_13(D)].b; + [t.c:23:12] pretmp_29 = &MEM [(void *)dst_13(D)].c.a; and PRE does [local count: 542239628]: [t.c:21:7] _1 = [t.c:21:7] MEM[(uint32_t *)dst_13(D)]; + [t.c:23:12] pretmp_29 = &MEM [(void *)dst_13(D)].c.a; [t.c:21:5] if (_1 == 1) ... - [local count: 184361475]: - [t.c:23:12] pb_17 = [t.c:23:29] &[t.c:23:34] [t.c:23:34] MEM[(struct b_t *)dst_13(D)].b; ... - [local count: 357878152]: - [t.c:29:12] pc_14 = [t.c:29:29] &[t.c:29:37] [t.c:29:34] [t.c:29:34] MEM[(struct c_t *)dst_13(D)].c.a; + [local count: 357878152]:
[Bug c++/105104] [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-03-30 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #3 from Richard Biener --- Please provide preprocessed source of a testcase.
[Bug c++/105061] [10/11/12 Regression] [c++2a+] anonymous bitfield templated offset rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105061 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4f2795218a6ba6a7b7b9b18ca7a6e390661e1608 commit r12-7913-g4f2795218a6ba6a7b7b9b18ca7a6e390661e1608 Author: Jakub Jelinek Date: Wed Mar 30 09:16:41 2022 +0200 c++: Fox template-introduction tentative parsing in class bodies clear colon_corrects_to_scope_p [PR105061] The concepts support (in particular template introductions from concepts TS) broke the following testcase, valid unnamed bitfields with dependent types (or even just typedefs) were diagnosed as typos (: instead of correct ::) in template introduction during their tentative parsing. The following patch fixes that by not doing this : to :: correction when member_p is true. 2022-03-30 Jakub Jelinek PR c++/105061 * parser.cc (cp_parser_template_introduction): If member_p, temporarily clear parser->colon_corrects_to_scope_p around tentative parsing of nested name specifier. * g++.dg/concepts/pr105061.C: New test.
[Bug c++/105061] [10/11/12 Regression] [c++2a+] anonymous bitfield templated offset rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105061 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7b5a2b6e4f78395962835790c6d4a3e27ab8d378 commit r11-9738-g7b5a2b6e4f78395962835790c6d4a3e27ab8d378 Author: Jakub Jelinek Date: Wed Mar 30 09:16:41 2022 +0200 c++: Fox template-introduction tentative parsing in class bodies clear colon_corrects_to_scope_p [PR105061] The concepts support (in particular template introductions from concepts TS) broke the following testcase, valid unnamed bitfields with dependent types (or even just typedefs) were diagnosed as typos (: instead of correct ::) in template introduction during their tentative parsing. The following patch fixes that by not doing this : to :: correction when member_p is true. 2022-03-30 Jakub Jelinek PR c++/105061 * parser.c (cp_parser_template_introduction): If member_p, temporarily clear parser->colon_corrects_to_scope_p around tentative parsing of nested name specifier. * g++.dg/concepts/pr105061.C: New test. (cherry picked from commit 4f2795218a6ba6a7b7b9b18ca7a6e390661e1608)
[Bug c++/105061] [10 Regression] [c++2a+] anonymous bitfield templated offset rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105061 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Summary|[10/11/12 Regression] |[10 Regression] [c++2a+] |[c++2a+] anonymous bitfield |anonymous bitfield |templated offset rejected |templated offset rejected Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Fixed for 11.3+ and 12.1+.
[Bug c++/105092] ICE with local with NULL DECL_CONTEXT on templatized OpenMP iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105092 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:410f39f56c14b195f066b9a18a3c6e8ffa03f848 commit r12-7915-g410f39f56c14b195f066b9a18a3c6e8ffa03f848 Author: Jakub Jelinek Date: Wed Mar 30 09:38:51 2022 +0200 openmp: Ensure DECL_CONTEXT of OpenMP iterators in templates [PR105092] cp_parser_omp_iterators does: DECL_ARTIFICIAL (iter_var) = 1; DECL_CONTEXT (iter_var) = current_function_decl; pushdecl (iter_var); on the newly created iterator vars, but when we instantiate templates containing them, we just tsubst_decl them (which apparently for automatic vars clears DECL_CONTEXT with a comment that pushdecl should be called on them later). The result is that we have automatic vars in the IL which have NULL DECL_CONTEXT and the analyzer is upset about those. Fixed by setting DECL_CONTEXT and calling pushdecl during the instantiation. 2022-03-30 Jakub Jelinek PR c++/105092 * pt.cc (tsubst_omp_clause_decl): When handling iterators, set DECL_CONTEXT of the iterator var to current_function_decl and call pushdecl. * g++.dg/gomp/pr105092.C: New test.
[Bug middle-end/99578] [11 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #40 from Martin Liška --- Can we close it as it was backported to gcc-11, Jakub?
[Bug sanitizer/102656] [11 Regression] ICE on coroutines on -fsanitize=address -O1 since r11-1613-g788b962aa00959e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102656 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug tree-optimization/104601] [11 Regression] Invalid branch elimination at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104601 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug target/104674] [11 Regression] i686 sse2: The two results of __divmoddi4 are mixed up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104674 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug tree-optimization/104675] [9/10 Regression] ICE: in expand_expr_real_2, at expr.cc:9773 at -O with __real__ + __imag__ extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104675 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE: |[9/10 Regression] ICE: in |in expand_expr_real_2, at |expand_expr_real_2, at |expr.cc:9773 at -O with |expr.cc:9773 at -O with |__real__ + __imag__ |__real__ + __imag__ |extraction |extraction --- Comment #13 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug target/104681] [9/10 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104681 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression]|[9/10 Regression] ppc64le |ppc64le |-mabi=ieeelongdouble ICE |-mabi=ieeelongdouble ICE|since r9-6460 |since r9-6460 | --- Comment #8 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug target/104775] [9/10 Regression] Failure to assemble on s390x with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104775 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression]|[9/10 Regression] Failure |Failure to assemble on |to assemble on s390x with |s390x with |-fsanitize=undefined |-fsanitize=undefined| --- Comment #6 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug target/104910] [10 Regression] ICE: internal consistency failure (error: invalid rtl sharing found in the insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104910 Jakub Jelinek changed: What|Removed |Added Summary|[10/11 Regression] ICE: |[10 Regression] ICE: |internal consistency|internal consistency |failure (error: invalid rtl |failure (error: invalid rtl |sharing found in the insn) |sharing found in the insn) --- Comment #5 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug rtl-optimization/104589] [11 Regression] Emitted binary code changes when -g is enabled at -O0 -flto and optimize attribute since r11-3026-gfea13fcd0da03535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104589 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug rtl-optimization/104814] [10 Regression] ifcvt: Deleting live variable in IF-CASE-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814 Jakub Jelinek changed: What|Removed |Added Summary|[10/11 Regression] ifcvt: |[10 Regression] ifcvt: |Deleting live variable in |Deleting live variable in |IF-CASE-2 |IF-CASE-2 --- Comment #9 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug c++/104568] [10 Regression] ICE [c++20] caused by option "-std=c++20 -Wall" when operand of operator new has size equal to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104568 Jakub Jelinek changed: What|Removed |Added Summary|[10/11 Regression] ICE |[10 Regression] ICE [c++20] |[c++20] caused by option|caused by option |"-std=c++20 -Wall" when |"-std=c++20 -Wall" when |operand of operator new has |operand of operator new has |size equal to 0 |size equal to 0 --- Comment #9 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug middle-end/99578] [11 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #41 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 99578, which changed state. Bug 99578 Summary: [11 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/101515] [11 Regression] ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128 since r11-6729-gadb520606ce3e1e1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Assignee|qinzhao at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #11 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug middle-end/104971] [9/10 Regression] Optimisation for __builtin_ia32_readeflags corrupts the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104971 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[9/10/11 Regression]|[9/10 Regression] |Optimisation for|Optimisation for |__builtin_ia32_readeflags |__builtin_ia32_readeflags |corrupts the stack |corrupts the stack --- Comment #9 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug c++/105035] [11 Regression] tree check: expected field_decl, have identifier_node in operand_equal_p, at fold-const.c:3335 since r11-5181-g0862d007b564eca8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed for 11.3 too.
[Bug c++/105092] ICE with local with NULL DECL_CONTEXT on templatized OpenMP iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105092 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/105094] [10/11/12 Regression] UBSAN in clear_bit_region(unsigned char*, unsigned int, unsigned int) (gimple-ssa-store-merging.cc:1834)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105094
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:387e818cda0ffde86f624228c3da1ab28f453685
commit r12-7916-g387e818cda0ffde86f624228c3da1ab28f453685
Author: Jakub Jelinek
Date: Wed Mar 30 10:21:16 2022 +0200
store-merging: Avoid ICEs on roughly ~0ULL/8 sized stores [PR105094]
On the following testcase on 64-bit targets, store-merging sees
a MEM_REF store from {} ctor with "negative" bitsize where bitoff + bitsize
wraps around to very small end offset. This later confuses the code
so that it allocates just a few bytes of memory but fills in huge amounts
of
it. Later on there is a param_store_merging_max_size size check but due to
the wrap-around we pass that.
The following patch punts on such large bitsizes.
2022-03-30 Jakub Jelinek
PR tree-optimization/105094
* gimple-ssa-store-merging.cc (mem_valid_for_store_merging): Punt
if
bitsize <= 0 rather than just == 0.
* gcc.dg/pr105094.c: New test.
[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #9 from Jiu Fu Guo ---
(In reply to Ian Lance Taylor from comment #8)
...
>
> package main
>
> func main() {
> for _, test := range []struct {
> x, y, want []int
> }{
> {[]int{}, []int{}, nil},
> {[]int{0}, []int{0}, []int{0}},
> } {
> p := test.x
> F(p)
> }
> }
>
> func F(v interface{}) {
> recover()
> println(cap(v.([]int)))
> }
>
> This can be compiled (though not run) using a cross-compiler without
> building libgo.
>
> The code coming into 280r.dse1 seems to be indexing from the end of the
> array. I see
>
> code_label 96 126 55 4 118 (nil) [0 uses])
> (note 55 96 56 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
> (insn 56 55 57 4 (set (reg:DI 144)
> (mult:DI (reg:DI 121 [ ivtmp_47 ])
> (const_int -72 [0xffb8]))) "foo.go":4:2 154 {muldi3}
> (nil))
> (insn 57 56 59 4 (set (reg/f:DI 145)
> (plus:DI (reg/f:DI 173)
> (reg:DI 144))) "foo.go":4:2 66 {*adddi3}
> (expr_list:REG_DEAD (reg/f:DI 173)
> (expr_list:REG_DEAD (reg:DI 144)
> (nil
>
> where earlier I see
>
> (insn 17 16 19 2 (set (mem/f/c:DI (plus:DI (reg/f:DI 110 sfp)
> (const_int 32 [0x20])) [8 GOTMP.5[0].x.__values+0 S8 A128])
> (reg/f:DI 117 [ _11 ])) "foo.go":4:23 670 {*movdi_internal64}
> (expr_list:REG_DEAD (reg/f:DI 117 [ _11 ])
> (nil)))
>
> and
>
> (insn 120 4 121 2 (set (reg/f:DI 173)
> (plus:DI (reg/f:DI 110 sfp)
> (const_int 32 [0x20]))) 66 {*adddi3}
> (nil))
>
> So register 173 is &GOTMP.5 although insn 120 doesn't indicate that. Then
> the 280r.dse1 pass drops out all the assignments to GOTMP.5, presumably
> because it doesn't understand that register 173 points to it.
Hi Ian!
Thanks for your great help!
[Bug sanitizer/105093] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105093 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e3e68fa59ead502c24950298b53c637bbe535a74 commit r12-7917-ge3e68fa59ead502c24950298b53c637bbe535a74 Author: Jakub Jelinek Date: Wed Mar 30 10:49:47 2022 +0200 ubsan: Fix ICE due to -fsanitize=object-size [PR105093] The following testcase ICEs, because for a volatile X & RESULT_DECL ubsan wants to take address of that reference. instrument_object_size is called with x, so the base is equal to the access and the var is automatic, so there is no risk of an out of bounds access for it. Normally we wouldn't instrument those because we fold address of the t - address of inner to 0, add constant size of the decl and it is equal to what __builtin_object_size computes. But the volatile results in the subtraction not being folded. The first hunk fixes it by punting if we access the whole automatic decl, so that even volatile won't cause a problem. The second hunk (not strictly needed for this testcase) is similar to what has been added to asan.cc recently, if we actually take address of a decl and keep it in the IL, we better mark it addressable. 2022-03-30 Jakub Jelinek PR sanitizer/105093 * ubsan.cc (instrument_object_size): If t is equal to inner and is a decl other than global var, punt. When emitting call to UBSAN_OBJECT_SIZE ifn, make sure base is addressable. * g++.dg/ubsan/pr105093.C: New test.
[Bug tree-optimization/105094] [10/11/12 Regression] UBSAN in clear_bit_region(unsigned char*, unsigned int, unsigned int) (gimple-ssa-store-merging.cc:1834)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105094
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:5c4767659c817dc4cec897215ca8f9ea930e309e
commit r11-9740-g5c4767659c817dc4cec897215ca8f9ea930e309e
Author: Jakub Jelinek
Date: Wed Mar 30 10:21:16 2022 +0200
store-merging: Avoid ICEs on roughly ~0ULL/8 sized stores [PR105094]
On the following testcase on 64-bit targets, store-merging sees
a MEM_REF store from {} ctor with "negative" bitsize where bitoff + bitsize
wraps around to very small end offset. This later confuses the code
so that it allocates just a few bytes of memory but fills in huge amounts
of
it. Later on there is a param_store_merging_max_size size check but due to
the wrap-around we pass that.
The following patch punts on such large bitsizes.
2022-03-30 Jakub Jelinek
PR tree-optimization/105094
* gimple-ssa-store-merging.c (mem_valid_for_store_merging): Punt if
bitsize <= 0 rather than just == 0.
* gcc.dg/pr105094.c: New test.
(cherry picked from commit 387e818cda0ffde86f624228c3da1ab28f453685)
[Bug sanitizer/105093] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105093 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:76a8ab576dbbe14b5a11e9feb454c3ca2f9b7e97 commit r11-9741-g76a8ab576dbbe14b5a11e9feb454c3ca2f9b7e97 Author: Jakub Jelinek Date: Wed Mar 30 10:49:47 2022 +0200 ubsan: Fix ICE due to -fsanitize=object-size [PR105093] The following testcase ICEs, because for a volatile X & RESULT_DECL ubsan wants to take address of that reference. instrument_object_size is called with x, so the base is equal to the access and the var is automatic, so there is no risk of an out of bounds access for it. Normally we wouldn't instrument those because we fold address of the t - address of inner to 0, add constant size of the decl and it is equal to what __builtin_object_size computes. But the volatile results in the subtraction not being folded. The first hunk fixes it by punting if we access the whole automatic decl, so that even volatile won't cause a problem. The second hunk (not strictly needed for this testcase) is similar to what has been added to asan.cc recently, if we actually take address of a decl and keep it in the IL, we better mark it addressable. 2022-03-30 Jakub Jelinek PR sanitizer/105093 * ubsan.c (instrument_object_size): If t is equal to inner and is a decl other than global var, punt. When emitting call to UBSAN_OBJECT_SIZE ifn, make sure base is addressable. * g++.dg/ubsan/pr105093.C: New test. (cherry picked from commit e3e68fa59ead502c24950298b53c637bbe535a74)
[Bug tree-optimization/105094] [10 Regression] UBSAN in clear_bit_region(unsigned char*, unsigned int, unsigned int) (gimple-ssa-store-merging.cc:1834)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105094 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] UBSAN |[10 Regression] UBSAN in |in |clear_bit_region(unsigned |clear_bit_region(unsigned |char*, unsigned int, |char*, unsigned int,|unsigned int) |unsigned int) |(gimple-ssa-store-merging.c |(gimple-ssa-store-merging.c |c:1834) |c:1834) | --- Comment #5 from Jakub Jelinek --- Fixed for 11.3+ and 12.1+.
[Bug sanitizer/105093] [9/10 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105093 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |9.5 Summary|ICE in |[9/10 Regression] ICE in |expand_expr_addr_expr_1, at |expand_expr_addr_expr_1, at |expr.c:7607 since |expr.c:7607 since |r6-3529-gf11a7b6d57f6fcba |r6-3529-gf11a7b6d57f6fcba Priority|P3 |P2 --- Comment #5 from Jakub Jelinek --- Fixed for 11.3+ and 12.1+.
[Bug c++/105077] The std::bad_array_new_length is not thrown for some new array scenarios.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105077 --- Comment #6 from Jonathan Wakely --- It's the same. In both cases the compiler fails to check if the size expression is erroneous, and calls operator new(n) with a bad value that causes a std::bad_alloc exception. I'm both cases, the compiler should be checking the expression first and throwing the correct exception.
[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104853 Kito Cheng changed: What|Removed |Added Last reconfirmed||2022-03-30 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #8 from Kito Cheng --- Hi rvalue: I pushed couple fixes to gcc 11 release branch, mostly back from trunk and a fix for setting right isa spec value: g:f41871dfdbd9d0c3368c0bc32d879fd5485e7abb I expect that could fix that issue, could you try again with top of gcc 11 branch? Thanks!
[Bug fortran/102043] [9/10/11/12 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #41 from Richard Biener --- -- random ideas dumping below -- so reading about ISO_Fortran_binding.h it seems to be that a base of the object isn't readily available and making it available would require quite some computation. staying with the current scheme of simply piggy-backing on C [] operator semantics which is, when facing a pointer that is being indexed, equivalent to pointer arithmetic which _can_ advance to before the indexed pointer, looks reasonable. that rules out using ARRAY_REF for all accesses through a descriptor (unless all strides are positive - not sure if it's worth special casing that though). it might be helpful to have a tree code providing CFI_address in an expanded form with explicitely specified index, [low-bound,] stride per indexed dimension and with the guarantee of CFI that the dimensions are independent (non-overlapping elements). I'd call it ELEMENT_SELECT_EXPR here, it would not be a tcc_reference since it only computes an address that would need to be dereferenced with a MEM_REF. Since it would be variable-length it doesn't nicely map to GIMPLE. Lowering during gimplification would be possible. Note we already have a vehicle that should be usable for the 1-dimensional case, namely TARGET_MEM_REF which allows variable pointer offsetting with a scaled index. Of course it would be somewhat abusing this and dependence analysis doesn't play nicely with it either AFAIK. Going for selected ARRAY_REF -> POINTER_PLUS_EXPR + MEM_REF lowering sounds like the way of least resistance, but then that's probably backwards of what the OpenACC folks want to do.
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #2 from vit9696 ---
Sure, the example is published on godbolt, but for completeness:
int main() {}
gcc -fprofile-arcs -S t.c -o t.s
cat t.s | grep gcda
Adding the mentioned arguments (e.g. -fprofile-prefix-map=/home/user=/test)
shows that it is not possible to make the output contain the desired:
.string "/test/t.gcda
But it will remain to be something like:
.string "/home/user/t.gcda
[Bug c++/105099] In lookup of namespace name qualifiers only namespaces should be considered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105099
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-03-30
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Jonathan Wakely ---
That wording was clarified by CWG 373:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#373
The issue says that G++ compiles the following:
namespace X {
namespace Y {
struct X {
void f()
{
using namespace X::Y;
namespace Z = X::Y;
}
};
}
}
However, I can't find any version of G++ that accepts it!
[Bug c++/105099] In lookup of namespace name qualifiers only namespaces should be considered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105099 --- Comment #2 from Jonathan Wakely --- Based on the issue submission date, Clark was probably talking about GCC 3.1 or similar. So maybe this is a regression since the new C++ parser was introduced.
[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105071 --- Comment #4 from Martin Jambor --- I have asked for permission to backport the fix in https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592520.html
[Bug target/104796] ABI change is not mentioned in HTML changelog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104796 --- Comment #3 from Jakub Jelinek --- https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592522.html
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #22 from Jakub Jelinek --- So, to sum up: aarch64, arm, x86-64 and riscv (last one since GCC 10 already) do ignore zero width bit-fields in argument/return value passing decisions and so have a C ABI incompatibility from earlier GCC versions. There is -Wpsabi diagnostics on affected argument/return value passing. powerpc64le and s390x do not ignore them, so have a C++ ABI incompatibility from earlier GCC versions. There is -Wpsabi diagnostics on affected argument/return value passing. alpha, arc, avr, bfin, bpf, c6x, cr16, cris, csky, epiphany, fr30, frv, ft32, gcn, h8300, i386 (32-bit), lm32, m32c, m32r, m68k, mcore, microblaze, mmix, mn10300, moxie, msp430, nds32, nios2, nvptx, or1k, pa, pdp11, powerpc (except for powerpc64le), pru, rl78, rx, sh, sparc, stormy16, tilegx, tilepro, v850, vax, visium and xtensa are not affected. ia64 and iq2000 are unknown. mips seems to be affected but nothing has been done about it, which means that right now if it is affected, it is not ignoring the zero width bit-fields without -Wpsabi diagnostics. Except for the not affected list and maybe unknown list, there was also an ABI change between G++ 4.4 and earlier and 4.5 and later.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
Jakub Jelinek changed:
What|Removed |Added
CC||hp at gcc dot gnu.org,
||mfortune at gmail dot com,
||paulhua at gcc dot gnu.org
--- Comment #23 from Jakub Jelinek ---
As for mips,
https://techpubs.jurassic.nl/manuals/0640/developer/Mpro_n32_ABI/sgi_html/ch02.html
says e.g.:
"Regardless of the struct field structure, it is treated as a sequence of
64-bit chunks. If a chunk consists solely of a double float field (but not a
double, which is part of a union), it is passed in a floating point register.
Any other chunk is passed in an integer register."
but it is ambiguous if in cases like:
struct A { double a; int : 0; double b; };
struct B { double a; int : 0; };
struct C { int : 0; double a; };
those zero width bit-fields are considered part of any chunk and if so, which
one (as they are zero size and on the chunk boundaries).
The return value rule seems less ambigous:
"A struct with only one or two floating point fields is returned in $f0 (and
$f2 if necessary). This is a generalization of the Fortran COMPLEX case."
my reading of that is that zero width bitfields shouldn't be ignored in that
case, because if they are present, the struct doesn't contain only one or two
floating point fields, it contains at least the zero width bitfield as well.
CCing MIPS maintainers on this (and also LoongArch, while there is no ABI
incompatibility for a new port, it is perhaps something to discuss and decide
too).
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 --- Comment #3 from Martin Liška --- > > But it will remain to be something like: > > .string "/home/user/t.gcda Well, -fprofile-prefix-map is about the mapping of the source file. So what exactly is your problem? Are the long filenames for .gcda files? What path length limitation does have an embedded target?
[Bug fortran/102043] [9/10/11/12 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #42 from Richard Biener --- Created attachment 52717 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52717&action=edit hack to rewrite all ARRA_REFs This shows a simple hack emitting *(&array + offset) from gfc_build_array_ref. That covers too many cases (as said, covering cases from array descriptor accesses should be enough). Appended is also testresults which show besides a large number of original tree dump scanning fails a few execute FAILs and a few ICEs where the gfortran frontend doesn't expect anything but an ARRAY_REF to be fed into select places (some already deal with an INDIRECT_REF as I found out). One such place is gfc_convert_array_to_string. As said, all this is probably backwards as to what the OpenACC folks desire.
[Bug fortran/105105] New: Fortran IEEE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105105 Bug ID: 105105 Summary: Fortran IEEE support Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- A meta-bug for Fortran IEEE support.
[Bug target/104796] ABI change is not mentioned in HTML changelog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104796 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug libquadmath/78415] sqrtq does not round correctly when round mode is upward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78415 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-03-30 CC||fxcoudert at gcc dot gnu.org
[Bug libquadmath/105101] incorrect rounding for sqrtq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101 Francois-Xavier Coudert changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-03-30 Status|UNCONFIRMED |NEW CC||fxcoudert at gcc dot gnu.org
[Bug c++/105106] New: Dependent invocation with defaulted NTTP lambda fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105106
Bug ID: 105106
Summary: Dependent invocation with defaulted NTTP lambda fails
Product: gcc
Version: 9.4.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/obfY3Mdba:
```C++
template
auto foo() {
return l;
}
template
auto bar() {
return foo();
}
```
The error message looks cut short:
```
: In function 'auto bar()':
:8:16: error: no matching function for call to 'foo()'
8 | return foo();
|^
:2:6: note: candidate: 'template auto foo()'
2 | auto foo() {
| ^~~
:2:6: note: template argument deduction/substitution failed:
```
[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105071 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:1dc4bed43760c4e291e072aa0c8c450f5775e25f commit r9-1-g1dc4bed43760c4e291e072aa0c8c450f5775e25f Author: Martin Jambor Date: Wed Mar 30 13:47:24 2022 +0200 cplxlower: Avoid a transform when looking at a default definition In PR 97456, IPA-SRA triggers a bug in tree-complex.c where it converts: a$_M_value_21 = COMPLEX_EXPR ; (where ISRA.18 is IPA-SRA created PARM_DECL with DECL_IGNORED_P set, which is why it only happens with IPA-SRA) into: a$_M_value_21 = COMPLEX_EXPR ; i.e. it replaces two uses of the parameter default-def with two uninitialized default-defs of a new variable - all in hope to produce code with better debug info. This patch fixes it by avoiding the transform when the SSA_NAME to be replaced is a default definition. gcc/ChangeLog: 2020-10-19 Martin Jambor PR tree-optimization/97456 PR middle-end/105071 * tree-complex.c (set_component_ssa_name): Do not replace ignored decl default definitions with new component vars. Reorder if conditions. gcc/testsuite/ChangeLog: 2020-10-19 Martin Jambor PR tree-optimization/97456 * gcc.dg/tree-ssa/pr97456.c: New test. (cherry picked from commit 619f91eaa8c8a50f1f9d3e7b96ee837037f0e806)
[Bug tree-optimization/97456] [10/11 Regression] An incorrect optimization causes a function to always return the same value when using -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:1dc4bed43760c4e291e072aa0c8c450f5775e25f commit r9-1-g1dc4bed43760c4e291e072aa0c8c450f5775e25f Author: Martin Jambor Date: Wed Mar 30 13:47:24 2022 +0200 cplxlower: Avoid a transform when looking at a default definition In PR 97456, IPA-SRA triggers a bug in tree-complex.c where it converts: a$_M_value_21 = COMPLEX_EXPR ; (where ISRA.18 is IPA-SRA created PARM_DECL with DECL_IGNORED_P set, which is why it only happens with IPA-SRA) into: a$_M_value_21 = COMPLEX_EXPR ; i.e. it replaces two uses of the parameter default-def with two uninitialized default-defs of a new variable - all in hope to produce code with better debug info. This patch fixes it by avoiding the transform when the SSA_NAME to be replaced is a default definition. gcc/ChangeLog: 2020-10-19 Martin Jambor PR tree-optimization/97456 PR middle-end/105071 * tree-complex.c (set_component_ssa_name): Do not replace ignored decl default definitions with new component vars. Reorder if conditions. gcc/testsuite/ChangeLog: 2020-10-19 Martin Jambor PR tree-optimization/97456 * gcc.dg/tree-ssa/pr97456.c: New test. (cherry picked from commit 619f91eaa8c8a50f1f9d3e7b96ee837037f0e806)
[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105071 Martin Jambor changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #6 from Martin Jambor --- Now fixed also on the gcc-9 branch. Sorry for not doing it earlier but I had not seen PR 97456 there before. *** This bug has been marked as a duplicate of bug 97456 ***
[Bug tree-optimization/97456] [10/11 Regression] An incorrect optimization causes a function to always return the same value when using -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456 Martin Jambor changed: What|Removed |Added CC||dlong at cadence dot com --- Comment #12 from Martin Jambor --- *** Bug 105071 has been marked as a duplicate of this bug. ***
[Bug c++/105099] [9/10/11/12 Regression] In lookup of namespace name qualifiers only namespaces should be considered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105099 Jonathan Wakely changed: What|Removed |Added Known to fail||10.3.1, 11.2.1, 12.0, ||4.1.2, 9.4.1 Summary|In lookup of namespace name |[9/10/11/12 Regression] In |qualifiers only namespaces |lookup of namespace name |should be considered|qualifiers only namespaces ||should be considered Known to work||3.2.3 --- Comment #3 from Jonathan Wakely --- It compiles with GCC 3.2.3, so marking as a regression. My guess is it broke with the new parser in 3.4 but I haven't confirmed it.
[Bug libquadmath/105101] incorrect rounding for sqrtq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jsm28 at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Trying
#include
#include
int
main ()
{
volatile long double ld = 0x2.4e5658b5f6d2a1ec21e3829dd7f8p+0L;
ld = sqrtl (ld);
printf ("%.50La\n", ld);
return 0;
}
on s390x-linux shows:
0x1.84bfedcba255aeaf7e99184e6f3b00p+0
but that is implemented using a hw instruction.
#include
#include
int
main ()
{
volatile __float128 ld = 0x2.4e5658b5f6d2a1ec21e3829dd7f8p+0Q;
ld = sqrtq (ld);
char buf[70];
quadmath_snprintf (buf, 69, "%.50Qa", ld);
printf ("%s\n", buf);
return 0;
}
on x86_64 indeed prints ...6f3a
The first testcase also prints ...6f3b on powerpc64le-linux, but again
that doesn't say much, because powerpc64le-linux __ieee754_sqrtf128
comes from sysdeps/powerpc/powerpc64/le/fpu/e_sqrtf128.c where in my case it is
implemented using soft-fp (and when glibc is configured for power9 or later
using hw instruction).
Seems libquadmath sqrtq.c isn't based on any glibc code, instead it uses sqrt
or sqrtl for initial approximation and then
/* Two Newton iterations. */
y -= 0.5q * (y - x / y);
y -= 0.5q * (y - x / y);
(or for sqrtl one iteration).
I bet that doesn't and can't guarantee correct rounding.
So, do we need to switch to soft-fp based implementation for it (we have a copy
already in libgcc/soft-fp), or do we have other options?
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #24 from Hans-Peter Nilsson --- (In reply to Jakub Jelinek from comment #23) > CCing MIPS maintainers on this (and also LoongArch, while there is no ABI > incompatibility for a new port, it is perhaps something to discuss and > decide too). Not a MIPS maintainer, and none of my targets are affected. While it seems likely I was just one the next line, there's a slight chance you meant to add someone else, which would be important and a valid reason for this long sentence and I think I'll stay CC:ed. :)
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #25 from Jakub Jelinek --- Sorry, apparently I must have misread the mmix below mips as being mips too.
[Bug c++/105106] Dependent invocation with defaulted NTTP lambda fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105106 --- Comment #1 from Johel Ernesto Guerrero Peña --- There is implementation divergence in the resulting closure type(s): https://godbolt.org/z/W98r49o8s.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #26 from Jakub Jelinek --- Reading the mips_function_arg code in detail, it seems it has been ignoring the zero width bitfields because it only checks for 64-bit aligned 64-bit double fields and if they appear, passes that part of struct in FPRs, otherwise in GPRs. So there is likely no change in that case from older releases (of course it is a question what the psABI wants). mips_fpr_return_fields seems to be affected, but the psABI wording (at least my reading thereof) seems to be that int:0; should make it return 0 like it now does (but didn't for C++ in 4.5 to 11). Thus maybe only -Wpsabi diagnostics for mips_fpr_return_fields is missing. Let me close this as a P1 for now then.
[Bug target/104796] ABI change is not mentioned in HTML changelog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104796 Bug 104796 depends on bug 102024, which changed state. Bug 102024 Summary: [12 Regression] zero width bitfields and ABIs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #27 from Xi Ruoyao ---
(In reply to Jakub Jelinek from comment #23)
> struct A { double a; int : 0; double b; };
For MIPS I've done some experiment with this and the result (with N64 ABI) is:
With GCC trunk, G++ trunk, and GCC 11.2: argument passed via FPR $f12 and GPR
$5,
returned via GPR $2 and $3
With G++ 11.2: argument passed via FPR $f12 and $f13, returned via FPR $f0 and
$f2
So I guess we need -Wpsabi for both mips_function_arg and
mips_fpr_return_fields.
[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #10 from Jiu Fu Guo ---
Created attachment 52718
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52718&action=edit
m.go sub1.go
Based on Ian's code, the below code also reproduce this issue.
package sub1
func TestBits(callback func(interface{})) {
for _, test := range []struct {
x, y, want []int
}{
{[]int{}, nil, nil},
{[]int{0}, nil, nil},
} {
p := test.x
callback(p)
}
}
---
> go1 sub1.go -quiet -O2 -o sub1.s
[Bug target/105068] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints: ssse3_pshufbv16qi3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105068 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:00d12a4a0fd56d8e9be1672e5e7637416b27fbb1 commit r11-9750-g00d12a4a0fd56d8e9be1672e5e7637416b27fbb1 Author: H.J. Lu Date: Mon Mar 28 09:32:53 2022 -0700 x86: Also use Yw in *ssse3_pshufbv8qi3 clobber PR target/105068 * config/i386/sse.md (*ssse3_pshufbv8qi3): Also replace "Yv" with "Yw" in clobber. (cherry picked from commit cccbb776589c1825de1bd2eefabb11d72ef28de8)
[Bug c++/93280] [10 Regression] ICE: in cp_gimplify_expr, at cp /cp-gimplify.c:933 since g:08f594eb399dab06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93280
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:f8c1f29a0b47b4b4a3c1506678f7ca2ce4b7ffbb
commit r12-7919-gf8c1f29a0b47b4b4a3c1506678f7ca2ce4b7ffbb
Author: Marek Polacek
Date: Fri Mar 25 17:46:07 2022 -0400
c++: ICE with aggregate assignment and DMI [PR104583]
The attached 93280 test no longer ICEs but looks like it was never added to
the
testsuite. The 104583 test, modified so that it closely resembles 93280,
still
ICEs.
The problem is that in 104583 we have a value-init from {} (the line A
a{};),
so this code in convert_like_internal
7960 /* If we're initializing from {}, it's value-initialization.
*/
7961 if (BRACE_ENCLOSED_INITIALIZER_P (expr)
7962 && CONSTRUCTOR_NELTS (expr) == 0
7963 && TYPE_HAS_DEFAULT_CONSTRUCTOR (totype)
7964 && !processing_template_decl)
7965 {
7966 bool direct = CONSTRUCTOR_IS_DIRECT_INIT (expr);
...
7974 TARGET_EXPR_DIRECT_INIT_P (expr) = direct;
sets TARGET_EXPR_DIRECT_INIT_P. This does not happen in 93280 where we
initialize from {0}.
In 104583, when gimplifying, the d = {}; line, we have
d = {.a=TARGET_EXPR >> }
where the TARGET_EXPR is the one with TARGET_EXPR_DIRECT_INIT_P set. In
gimplify_init_ctor_preeval we do
4724 FOR_EACH_VEC_SAFE_ELT (v, ix, ce)
4725 gimplify_init_ctor_preeval (&ce->value, pre_p, post_p, data);
so we gimplify the TARGET_EXPR, crashing at
744 case TARGET_EXPR:
745 /* A TARGET_EXPR that expresses direct-initialization should
have
been
746 elided by cp_gimplify_init_expr. */
747 gcc_checking_assert (!TARGET_EXPR_DIRECT_INIT_P (*expr_p));
but there is no INIT_EXPR so cp_gimplify_init_expr was never called!
Now, the fix for c++/93280
says "let's only set TARGET_EXPR_DIRECT_INIT_P when we're using the DMI in
a constructor." and the comment talks about the full initialization. Is
is accurate to say that our TARGET_EXPR does not represent the full
initialization, because it only initializes the 'a' subobject? If so,
then maybe get_nsdmi should clear TARGET_EXPR_DIRECT_INIT_P when in_ctor
is false.
I've compared the 93280.s and 104583.s files, they differ only in one
movl $0, so there are no extra calls and similar.
PR c++/93280
PR c++/104583
gcc/cp/ChangeLog:
* init.cc (get_nsdmi): Set TARGET_EXPR_DIRECT_INIT_P to in_ctor.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/nsdmi-list7.C: New test.
* g++.dg/cpp0x/nsdmi-list8.C: New test.
[Bug c++/104583] [10/11/12 regression] ICE dolphin-emu at cp/cp-gimplify.cc:746
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104583
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:f8c1f29a0b47b4b4a3c1506678f7ca2ce4b7ffbb
commit r12-7919-gf8c1f29a0b47b4b4a3c1506678f7ca2ce4b7ffbb
Author: Marek Polacek
Date: Fri Mar 25 17:46:07 2022 -0400
c++: ICE with aggregate assignment and DMI [PR104583]
The attached 93280 test no longer ICEs but looks like it was never added to
the
testsuite. The 104583 test, modified so that it closely resembles 93280,
still
ICEs.
The problem is that in 104583 we have a value-init from {} (the line A
a{};),
so this code in convert_like_internal
7960 /* If we're initializing from {}, it's value-initialization.
*/
7961 if (BRACE_ENCLOSED_INITIALIZER_P (expr)
7962 && CONSTRUCTOR_NELTS (expr) == 0
7963 && TYPE_HAS_DEFAULT_CONSTRUCTOR (totype)
7964 && !processing_template_decl)
7965 {
7966 bool direct = CONSTRUCTOR_IS_DIRECT_INIT (expr);
...
7974 TARGET_EXPR_DIRECT_INIT_P (expr) = direct;
sets TARGET_EXPR_DIRECT_INIT_P. This does not happen in 93280 where we
initialize from {0}.
In 104583, when gimplifying, the d = {}; line, we have
d = {.a=TARGET_EXPR >> }
where the TARGET_EXPR is the one with TARGET_EXPR_DIRECT_INIT_P set. In
gimplify_init_ctor_preeval we do
4724 FOR_EACH_VEC_SAFE_ELT (v, ix, ce)
4725 gimplify_init_ctor_preeval (&ce->value, pre_p, post_p, data);
so we gimplify the TARGET_EXPR, crashing at
744 case TARGET_EXPR:
745 /* A TARGET_EXPR that expresses direct-initialization should
have
been
746 elided by cp_gimplify_init_expr. */
747 gcc_checking_assert (!TARGET_EXPR_DIRECT_INIT_P (*expr_p));
but there is no INIT_EXPR so cp_gimplify_init_expr was never called!
Now, the fix for c++/93280
says "let's only set TARGET_EXPR_DIRECT_INIT_P when we're using the DMI in
a constructor." and the comment talks about the full initialization. Is
is accurate to say that our TARGET_EXPR does not represent the full
initialization, because it only initializes the 'a' subobject? If so,
then maybe get_nsdmi should clear TARGET_EXPR_DIRECT_INIT_P when in_ctor
is false.
I've compared the 93280.s and 104583.s files, they differ only in one
movl $0, so there are no extra calls and similar.
PR c++/93280
PR c++/104583
gcc/cp/ChangeLog:
* init.cc (get_nsdmi): Set TARGET_EXPR_DIRECT_INIT_P to in_ctor.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/nsdmi-list7.C: New test.
* g++.dg/cpp0x/nsdmi-list8.C: New test.
[Bug sanitizer/105107] New: false positive stack-buffer-overflow in ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105107
Bug ID: 105107
Summary: false positive stack-buffer-overflow in ASAN
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
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: ---
Hi,
For the following code, ASAN in gcc-O0 since 9.0 reported a
"stack-buffer-overflow", which it shouldn't.
$cat a.c
#define c(d, j) d = 5;
h=1;
*a=&h;
**b = &a;
int e;
fn1() {
int e=0;
int **f = &a;
*f = &e;
}
i() {
int g[9];
c(**b, )
}
main() {
fn1();
i();
}
$
$gcc -fsanitize=address -O0 a.c;./a.out
==1==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffef6656070
at pc 0x00401390 bp 0x7ffef6656000 sp 0x7ffef6655ff8
WRITE of size 4 at 0x7ffef6656070 thread T0
#0 0x40138f in i /app/example.c:13
#1 0x4013e8 in main /app/example.c:17
#2 0x7f5a7f21c0b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
#3 0x4010ed in _start (/app/output.s+0x4010ed)
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #28 from Jakub Jelinek ---
(In reply to Xi Ruoyao from comment #27)
> (In reply to Jakub Jelinek from comment #23)
>
> > struct A { double a; int : 0; double b; };
>
> For MIPS I've done some experiment with this and the result (with N64 ABI)
> is:
>
> With GCC trunk, G++ trunk, and GCC 11.2: argument passed via FPR $f12 and
> GPR $5,
> returned via GPR $2 and $3
Ah, indeed.
The
for (; field; field = DECL_CHAIN (field))
if (TREE_CODE (field) == FIELD_DECL
&& int_bit_position (field) >= bitpos)
break;
loop will simply stop on the first field with bitpos equal or greater than
bitpos, so the zero sized bit-fields (and generally any other zero sized fields
like struct S {} s; in GNU C) will be treated as being part of the next slot.
So in struct B { int : 0; double a, b; }; it will go into GPR and FPR,
while struct C { double a; int : 0; double b; }; into FPR and GPR, and
struct D { double a, b; int : 0; } into FPR & FPR.
> With G++ 11.2: argument passed via FPR $f12 and $f13, returned via FPR $f0
> and $f2
>
> So I guess we need -Wpsabi for both mips_function_arg and
> mips_fpr_return_fields.
Is there somebody who can clarify the MIPS ABI intent?
Also, what does LLVM do?
[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091 --- Comment #11 from Jiu Fu Guo --- Find one difference between trunk and r12-656: On trunk: tree expr = MEM_EXPR (mem); where mem is (mem/f/c:DI (plus:DI (reg/f:DI 110 sfp) (const_int 32 [0x20])) [3 GOTMP.2[0].x.__values+0 S8 A128]) and then expr is GOTMP.2[0].x.__values base = get_base_address (expr); base is "GOTMP.2" "may_be_aliased (base)" returns false. On r12-656: "may_be_aliased (base)" returns true. may_be_aliased checks TREE_ADDRESSABLE which also returns differences between trunk and r12-656.
[Bug c++/104583] [10/11 regression] ICE dolphin-emu at cp/cp-gimplify.cc:746
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104583 Marek Polacek changed: What|Removed |Added Summary|[10/11/12 regression] ICE |[10/11 regression] ICE |dolphin-emu at |dolphin-emu at |cp/cp-gimplify.cc:746 |cp/cp-gimplify.cc:746 --- Comment #7 from Marek Polacek --- Fixed on trunk so far.
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #30 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6a777ceb0e975f0efc823d2d82e676346f068151 commit r12-7920-g6a777ceb0e975f0efc823d2d82e676346f068151 Author: Jakub Jelinek Date: Wed Mar 30 16:04:52 2022 +0200 testsuite: Change pr80334.C testcase to dg-do compile [PR102772] The testcase has UB at runtime, placement new shouldn't construct an object with certain alignment requirements into an unaligned buffer. 2022-03-30 Jakub Jelinek PR tree-optimization/80334 PR target/102772 * g++.dg/torture/pr80334.C: Change from dg-do run to dg-do compile.
[Bug tree-optimization/80334] [5 Regression] Segfault when taking address of copy of unaligned struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80334 --- Comment #15 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6a777ceb0e975f0efc823d2d82e676346f068151 commit r12-7920-g6a777ceb0e975f0efc823d2d82e676346f068151 Author: Jakub Jelinek Date: Wed Mar 30 16:04:52 2022 +0200 testsuite: Change pr80334.C testcase to dg-do compile [PR102772] The testcase has UB at runtime, placement new shouldn't construct an object with certain alignment requirements into an unaligned buffer. 2022-03-30 Jakub Jelinek PR tree-optimization/80334 PR target/102772 * g++.dg/torture/pr80334.C: Change from dg-do run to dg-do compile.
[Bug c++/100474] ICE: in diagnose_trait_expr, at cp/constraint.cc:3706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100474 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:3aaf9bf77047aecc23072fe3db7f13ecff72a7cf commit r12-7921-g3aaf9bf77047aecc23072fe3db7f13ecff72a7cf Author: Patrick Palka Date: Wed Mar 30 10:13:11 2022 -0400 c++: ICE with failed __is_constructible constraint [PR100474] Here we're crashing when diagnosing an unsatisfied __is_constructible constraint because diagnose_trait_expr doesn't recognize this trait (along with a bunch of other traits). Fix this by adding handling for all remaining traits and removing the default case so that when adding a new trait we'll get a warning that diagnose_trait_expr needs to handle it. PR c++/100474 gcc/cp/ChangeLog: * constraint.cc (diagnose_trait_expr): Handle all remaining traits appropriately. Remove default case. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-traits3.C: New test.
[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091 --- Comment #12 from Jiu Fu Guo --- In dse.cc, "may_be_aliased" affects "can_escape" and then affects "kill_on_calls".
[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Last reconfirmed||2022-03-30
--- Comment #13 from Richard Biener ---
[local count: 715863673]:
# ivtmp_47 = PHI <1(3), 2(2)>
_43 = ivtmp_47 * 18446744073709551544;
GOTMP.8 = MEM[(struct *)&GOTMP.5 + 144B + _43 * 1];
GOTMP.13 = GOTMP.8;
test = GOTMP.13;
p = test.x;
D.483.__type_descriptor = &g.type.._6_7int;
GOTMP.14 = p;
D.483.__object = &GOTMP.14;
main.F (D.483);
p ={v} {CLOBBER(eol)};
if (ivtmp_47 != 1)
goto ; [66.67%]
else
goto ; [33.33%]
[local count: 357878152]:
test ={v} {CLOBBER(eol)};
return;
that's an interesting sequence of aggregate copies (meh - SRA should
optimize those!) and an interesting choice of IVs but nothing invalid.
We expand the
GOTMP.8 = MEM[(struct *)&GOTMP.5 + 144B + _43 * 1];
stmt to memcpy() but GOTMP.5 is not TREE_ADDRESSABLE here. That might
in the end lead DSE to remove the stores. When setting the flag
inside gdb during expansion I see the stores are retained.
Now, emit_block_op_via_libcall does
/* Since dst and src are passed to a libcall, mark the corresponding
tree EXPR as addressable. */
tree dst_expr = MEM_EXPR (dst);
tree src_expr = MEM_EXPR (src);
if (dst_expr)
mark_addressable (dst_expr);
if (src_expr)
mark_addressable (src_expr);
but mark_addressable doesn't handle TARGET_MEM_REF.
Does the following fix the runtime error? The RTL after DSE seems to be OK.
diff --git a/gcc/gimple-expr.cc b/gcc/gimple-expr.cc
index f9a650b5daf..5faaf43eaf5 100644
--- a/gcc/gimple-expr.cc
+++ b/gcc/gimple-expr.cc
@@ -910,7 +910,8 @@ mark_addressable (tree x)
x = TREE_OPERAND (x, 0);
while (handled_component_p (x))
x = TREE_OPERAND (x, 0);
- if (TREE_CODE (x) == MEM_REF
+ if ((TREE_CODE (x) == MEM_REF
+ || TREE_CODE (x) == TARGET_MEM_REF)
&& TREE_CODE (TREE_OPERAND (x, 0)) == ADDR_EXPR)
x = TREE_OPERAND (TREE_OPERAND (x, 0), 0);
if (!VAR_P (x)
[Bug c++/100474] ICE: in diagnose_trait_expr, at cp/constraint.cc:3706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100474 Patrick Palka changed: What|Removed |Added Target Milestone|--- |11.3 Known to work||12.0 --- Comment #5 from Patrick Palka --- Fixed for GCC 12 so far.
[Bug c++/101030] [9/10/11/12 Regression] ICE with -Wconversion and a?:b extension in template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101030 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:5db9ce171019f8915885cebd5cc5f4101bb926e6 commit r12-7922-g5db9ce171019f8915885cebd5cc5f4101bb926e6 Author: Marek Polacek Date: Tue Mar 29 14:36:55 2022 -0400 c-family: ICE with -Wconversion and A ?: B [PR101030] This patch fixes a crash in conversion_warning on a null expression. It is null because the testcase uses the GNU A ?: B extension. We could also use op0 instead of op1 in this case, but it doesn't seem to be necessary. PR c++/101030 gcc/c-family/ChangeLog: * c-warn.cc (conversion_warning) : Don't call conversion_warning when OP1 is null. gcc/testsuite/ChangeLog: * g++.dg/ext/cond5.C: New test.
[Bug c++/101030] [9/10/11 Regression] ICE with -Wconversion and a?:b extension in template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101030 Marek Polacek changed: What|Removed |Added Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE |with -Wconversion and a?:b |with -Wconversion and a?:b |extension in template |extension in template |argument|argument --- Comment #5 from Marek Polacek --- Fixed on trunk so far, will backport to 11 too.
[Bug sanitizer/105107] false positive stack-buffer-overflow in ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105107
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Martin Liška ---
There's expanded version of the testcase:
$ cat pr105107.c
int h=1;
int *a=&h;
int **b = &a;
int e;
void
fn1() {
int e=0;
int **f = &a;
__builtin_printf ("addr of e=%p\n", &e);
*f = &e;
}
void
i() {
int g[9];
__builtin_printf ("write to %p\n", *b);
**b = 5;
}
int
main() {
fn1();
i();
return 0;
}
$ gcc-11 pr105107.c -fsanitize=address -g && ./a.out
addr of e=0x7fffdaf0
write to 0x7fffdaf0
=
==6753==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fffdaf0 at pc 0x00401416 bp 0x7fffda80 sp 0x7fffda78
WRITE of size 4 at 0x7fffdaf0 thread T0
#0 0x401415 in i /home/marxin/Programming/testcases/pr105107.c:19
#1 0x401493 in main /home/marxin/Programming/testcases/pr105107.c:25
#2 0x773be62f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#3 0x773be6ef in __libc_start_main_impl ../csu/libc-start.c:392
#4 0x4010f4 in _start (/home/marxin/Programming/testcases/a.out+0x4010f4)
Address 0x7fffdaf0 is located in stack of thread T0 at offset 96 in frame
#0 0x401305 in i /home/marxin/Programming/testcases/pr105107.c:16
This frame has 1 object(s):
[48, 84) 'g' (line 17) <== Memory access at offset 96 overflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
/home/marxin/Programming/testcases/pr105107.c:19 in i
Shadow bytes around the buggy address:
0x10007fff7b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007fff7b50: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 04 f3[f3]f3
0x10007fff7b60: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
Shadow gap: cc
==6753==ABORTING
The error is correct as it takes the address of 'e' in function 'fn1' where it
writes once fn1 returns.
[Bug c++/101030] [9/10/11 Regression] ICE with -Wconversion and a?:b extension in template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101030 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:511e8b612287ad828c60f2f12c500ccfa26c275c commit r11-9751-g511e8b612287ad828c60f2f12c500ccfa26c275c Author: Marek Polacek Date: Tue Mar 29 14:36:55 2022 -0400 c-family: ICE with -Wconversion and A ?: B [PR101030] This patch fixes a crash in conversion_warning on a null expression. It is null because the testcase uses the GNU A ?: B extension. We could also use op0 instead of op1 in this case, but it doesn't seem to be necessary. PR c++/101030 gcc/c-family/ChangeLog: * c-warn.c (conversion_warning) : Don't call conversion_warning when OP1 is null. gcc/testsuite/ChangeLog: * g++.dg/ext/cond5.C: New test. (cherry picked from commit 5db9ce171019f8915885cebd5cc5f4101bb926e6)
[Bug c++/101030] [9/10 Regression] ICE with -Wconversion and a?:b extension in template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101030 Marek Polacek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE|[9/10 Regression] ICE with |with -Wconversion and a?:b |-Wconversion and a?:b |extension in template |extension in template |argument|argument Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Marek Polacek --- Fixed.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #29 from Xi Ruoyao --- > Is there somebody who can clarify the MIPS ABI intent? > Also, what does LLVM do? I've CC'ed Yunqiang and Fangrui. And I'll build clang for MIPS to see...
[Bug debug/105108] New: incomplete/incorrect DWARF information at -O1 and -Og after inlining a function returning a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
Bug ID: 105108
Summary: incomplete/incorrect DWARF information at -O1 and -Og
after inlining a function returning a constant
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: assaiante at diag dot uniroma1.it
Target Milestone: ---
In this minimized C example, variable l_144 is not available when debugging
(optimized out) when used in the assignment of variable a.
We found this odd since -O2/-O3 generate nearly identical ASM but with complete
debug information for l_144. At -O1/-Og the DIE of the variable misses instead
the const value attribute.
We were not able to pinpoint the root cause to a specific compilation option,
but suspect an interaction of inlining and constant propagation. We provide
below additional analysis for x64.
Then, much to our surprise, when we modify line 4 to assign l_144 with e.g. 8,
the debugger shows 8 instead of 0 as its value at line 7, therefore exposing
incorrect debug information. At a first look, this happened also with -O2/O3:
however, we then found -O2/-O3 DWARF information to be correct (also, lldb
displays 0), with the issue likely being a bug in gdb that we will report
separately.
$ cat a.c
int a;
char b() { return 0; }
int main() {
char l_144;
short l_165 = 128;
l_144 = b();
a = l_144 != l_165;
}
GCC and GDB version (GCC commit id: 500d3f0a302):
> gcc (GCC) 12.0.0 20211227 (experimental)
> GNU gdb (GDB) 11.2
GDB trace:
$ gcc -Og -g a.c -o opt
$ gdb opt
Reading symbols from opt...
(gdb) b 7
Breakpoint 1 at 0x40048c: file a.c, line 7.
(gdb) r
Starting program: /home/stepping/35/reduce/opt
Breakpoint 1, main () at a.c:7
7 a = l_144 != l_165;
(gdb) info locals
l_144 =
l_165 = 128
ASM at Og (identical at O1):
0040048c :
40048c: c7 05 96 0b 20 00 01movl $0x1,0x200b96(%rip)#
60102c
400493: 00 00 00
400496: b8 00 00 00 00 mov$0x0,%eax
40049b: c3 retq
40049c: 0f 1f 40 00 nopl 0x0(%rax)
DWARF at Og (identical at O1):
0x0049: DW_TAG_subprogram
DW_AT_external (true)
DW_AT_name ("main")
DW_AT_decl_file ("/home/stepping/35/reduce/a.c")
DW_AT_decl_line (3)
DW_AT_decl_column (0x05)
DW_AT_type (0x0042 "int")
DW_AT_low_pc(0x0040048c)
DW_AT_high_pc (0x0040049c)
DW_AT_frame_base(DW_OP_call_frame_cfa)
DW_AT_call_all_calls(true)
DW_AT_sibling (0x0085)
0x006b: DW_TAG_variable
DW_AT_name("l_144")
DW_AT_decl_file ("/home/stepping/35/reduce/a.c")
DW_AT_decl_line (4)
DW_AT_decl_column (0x08)
DW_AT_type(0x0085 "char")
0x0077: DW_TAG_variable
DW_AT_name("l_165")
DW_AT_decl_file ("/home/stepping/35/reduce/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column (0x09)
DW_AT_type(0x008c "short int")
DW_AT_const_value (0x80)
At higher optimization levels the ASM is nearly the same, except the use of xor
instead of mov to set the return value to zero:
004003a0 :
4003a0: c7 05 82 0c 20 00 01movl $0x1,0x200c82(%rip)#
60102c
4003a7: 00 00 00
4003aa: 31 c0 xor%eax,%eax
4003ac: c3 retq
4003ad: 0f 1f 00nopl (%rax)
But the variable is correctly visible when stepping on line 7 since the const
value attribute is present in its debug information:
0x0045: DW_TAG_subprogram
DW_AT_external (true)
DW_AT_name ("main")
DW_AT_decl_file ("/home/stepping/35/reduce/a.c")
DW_AT_decl_line (3)
DW_AT_decl_column (0x05)
DW_AT_type (0x003e "int")
DW_AT_low_pc(0x004003a0)
DW_AT_high_pc (0x004003ad)
DW_AT_frame_base(DW_OP_call_frame_cfa)
DW_AT_call_all_calls(true)
DW_AT_sibling (0x0080)
0x0067: DW_TAG_variable
DW_AT_name("l_144")
DW_AT_decl_line (4)
DW_AT_decl_column (0x08)
DW_AT_type(0x0080 "char")
DW_AT_const_value (0x00)
0x0073: DW_TAG_variable
DW_AT_name("l_165")
DW_AT_decl_line (
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||redi at gcc dot gnu.org --- Comment #31 from Jakub Jelinek --- Oops, the above commit is an error, there is no placement new and it is about the alignment returned by operator new. movdqu (%eax), %xmm7 movaps %xmm7, (%edx) where %edx is the value returned by _Znwj. Now, in C++14 the testcase might be invalid if it operator new doesn't guarantee 16-byte alignment. But shouldn't C++17 and later call _ZnwjSt11align_val_t instead of _Znwj if the latter doesn't guarantee 16-byte alignment? The threshold above which _ZnwjSt11align_val_t is used is computed by malloc_alignment: return MAX (max_align_t_align(), MALLOC_ABI_ALIGNMENT); and max_align_t_align() is 8643 unsigned int max_align = MAX (TYPE_ALIGN (long_long_integer_type_node), 8644TYPE_ALIGN (long_double_type_node)); 8645 if (float128_type_node != NULL_TREE) 8646max_align = MAX (max_align, TYPE_ALIGN (float128_type_node)); 8647 return max_align; TYPE_ALIGN of the 3 types are 64-bit, 32-bit and 128-bit for 32-bit Solaris. So, if 32-bit Solaris doesn't guarantee 128-bit alignment from malloc, I'm afraid it needs to somehow override this so that max_align_t_align() is only 64-bit. Or perhaps avoid supporting float128_type_node. Or in libsupc++ ensure 16-byte alignment from operator new by using posix_memalign etc.
[Bug sanitizer/105107] false positive stack-buffer-overflow in ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105107 --- Comment #2 from Li Shaohua --- Thanks for your prompt reply. The warning messages only appeared for -O0 and -O3, not for -O1 and -O2. I wonder this might also be an issue.
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #32 from Jonathan Wakely --- Yes, this is a well known problem that stddef.h's max_align_t does not agree with malloc on i386 Solaris. Glibc used to have the same problem. Fixing it in the compiler or in operator new seems reasonable. I'll try doing the latter.
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #33 from Jonathan Wakely --- (IMHO we should never have added float128 to max_align_t for targets where we can't change malloc, but that was decided long ago).
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #34 from Jonathan Wakely --- Assuming that posix_memalign is slower than malloc (which seems likely), it would be better to fix this in the compiler by defining __STDCPP_DEFAULT_NEW_ALIGNMENT__=8 for i386 solaris, instead of setting it to alignof(max_align_t). That matches what malloc actualy guarantees on the target. That would mean that new int[4] can still use malloc, because the compiler knows the alignment here is 4 and it can just use _Znwj. But for new __float128 it would use _ZnwjSt11align_val_t to get 16-byte alignment that isn't guaranteed by malloc. Fixing it in _Znwj inside libsupc++ means that we have to use posix_memalign for all allocations >= 16 bytes, as we can't tell whether operator new(16) was called for something that actually needs 16-byte alignment, or for something like int[4] or short[8].
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=77691
--- Comment #35 from Jonathan Wakely ---
That said, this would probably fix it:
--- a/libstdc++-v3/libsupc++/new_op.cc
+++ b/libstdc++-v3/libsupc++/new_op.cc
@@ -41,6 +41,11 @@ extern "C" void *malloc (std::size_t);
_GLIBCXX_WEAK_DEFINITION void *
operator new (std::size_t sz) _GLIBCXX_THROW (std::bad_alloc)
{
+#if defined __sun && defined __i386__
+ if (sz >= 16)
+return ::operator new(sz, std::align_val_t(16));
+#endif
+
void *p;
/* malloc (0) is unpredictable; avoid it. */
As noted in PR 77691, there are other targets where GCC's max_align_t does not
match the target malloc. That includes vxworks and mingw*.
[Bug target/104414] [AArch64] About the condition of calls_alloca in aarch64_layout_frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104414 Richard Earnshaw changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Richard Earnshaw --- Not a bug report
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #36 from Jakub Jelinek --- Created attachment 52719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52719&action=edit gcc12-pr102772.patch So like this?
[Bug tree-optimization/105109] New: [12 Regression] False positive warning on complex float code since r12-155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109
Bug ID: 105109
Summary: [12 Regression] False positive warning on complex
float code since r12-155
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since r12-155-gd8e1f1d24179690fd9c0f63c27b12e030010d9ea with -O -Wall on
static void foo(int dim,float _Complex f0[])
{
int d;
f0[0] -= 3.14;
for (d = 0; d < dim; ++d) f0[0] += 3.14;
}
void bar(int dim, const float _Complex u_t[], float _Complex f0[])
{
float _Complex exp[1] = {0.};
foo(dim, exp);
f0[0] = u_t[0] - exp[0];
}
we emit
In function ‘foo’,
inlined from ‘bar’ at rh2066856.c:10:3:
rh2066856.c:4:9: warning: ‘exp[0]’ is used uninitialized [-Wuninitialized]
4 | f0[0] -= 3.14;
| ~~^~~
rh2066856.c: In function ‘bar’:
rh2066856.c:9:18: note: ‘exp[0]’ was declared here
9 | float _Complex exp[1] = {0.};
| ^~~
Before dce3 we have:
IMAGPART_EXPR = 0.0;
REALPART_EXPR = -3.141049041748046875e+0;
and then only read or modify REALPART_EXPR before final
exp$0 ={v} {CLOBBER};
dce3 seems to decide that because nothing reads IMAGPART_EXPR , the
store of it is useless too.
And later on, ccp3 puts exp$0 into SSA form and changes it into:
_5 = IMAGPART_EXPR ;
exp$0_26 = COMPLEX_EXPR <-3.141049041748046875e+0, _5>;
and
_1 = IMAGPART_EXPR ;
exp$0_11 = COMPLEX_EXPR <_19, _1>;
etc.
And the uninit1 pass later complains because the second argument of
COMPLEX_EXPR is IMAGPART_EXPR of uninitialized SSA_NAME.
So, should DCE avoid doing that? Or better when turning it into SSA form find
out that only one half of it is ever used and just rewrite that half into a
SSA_NAME?
[Bug tree-optimization/105109] [12 Regression] False positive warning on complex float code since r12-155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-03-30 Priority|P3 |P1 Target Milestone|--- |12.0
[Bug c++/105110] New: NTTP type deduction fails when dependent of previous NTTPs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105110
Bug ID: 105110
Summary: NTTP type deduction fails when dependent of previous
NTTPs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: j.galecki11 at gmail dot com
Target Milestone: ---
Consider the following minimal example:
```
template
struct S {};
template
struct V {};
template s>
void foo(V) {}
void bar() {
constexpr S<1> s;
foo(V{});
}
```
CE link for the reader's convenience: https://godbolt.org/z/1cYK9s1Ta
GCC fails to compile this (consistent across versions), complaining about
cv-qualifier mismatch, which seems wholly irrelevant. Clang compiles without
warnings.
The problem is that when instantiating a function parametrized with a NTTP, GCC
fails to deduce the type of the NTTP parameter based on the other function
parameters. This causes problems with passing around constexpr values, as shown
in the following second example: https://godbolt.org/z/3Tnjx1Wxb (again, Clang
compiles and executes as intended).
As I cannot quite figure out whether the standard requires the deduction
described above to be possible, I see 2 possibilities:
1) This is simply a bug in GCC.
2) GCC is correct in refusing to compile the provided examples (Clang is
wrong). In this case, the emitted error should probably better describe the
problem.
[Bug fortran/105105] [Meta] Fortran IEEE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105105 kargl at gcc dot gnu.org changed: What|Removed |Added Depends on||67531, 69101, 78314, 82968, ||91690, 95640, 95644, 100662 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Add to the "Depends on" list. Note, both Fortran 2018 and 2023 need to be reviewed for completeness. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67531 [Bug 67531] No IEEE rounding support for powerpc long double type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69101 [Bug 69101] [F03] IEEE_SELECTED_REAL_KIND is not generic https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 [Bug 78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82968 [Bug 82968] gfortran.dg/ieee/ieee_6.f90 fails at -O0 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91690 [Bug 91690] Slow IEEE intrinsics https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 [Bug 95640] gfortran ieee_selected_real_kind returns 10 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 [Bug 95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 [Bug 100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
[Bug libquadmath/105101] incorrect rounding for sqrtq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #1) > So, do we need to switch to soft-fp based implementation for it (we have a > copy already in libgcc/soft-fp), or do we have other options? https://cgit.freebsd.org/src/tree/lib/msun/src/e_sqrtl.c The above worked on FreeBSD-sparc64. Support for sparc64 has been dropped by FreeBSD. It is used on at least FreeBSd-aarch64, but I've never tested it there.
[Bug libquadmath/105101] incorrect rounding for sqrtq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #2) > (In reply to Jakub Jelinek from comment #1) > > > So, do we need to switch to soft-fp based implementation for it (we have a > > copy already in libgcc/soft-fp), or do we have other options? > > > https://cgit.freebsd.org/src/tree/lib/msun/src/e_sqrtl.c > > The above worked on FreeBSD-sparc64. Support for > sparc64 has been dropped by FreeBSD. It is used on > at least FreeBSd-aarch64, but I've never tested it > there. Forgot to mention. See long comment at end of https://cgit.freebsd.org/src/tree/lib/msun/src/e_sqrt.c
[Bug ada/80869] Ada.Directories is missing Name_Case_Equivalence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80869 --- Comment #1 from simon at pushface dot org --- This was fixed 4 years ago.
[Bug ada/80869] Ada.Directories is missing Name_Case_Equivalence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80869 Arnaud Charlet changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |9.4 CC||charlet at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Arnaud Charlet --- Great, thanks for checking!
[Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032 --- Comment #10 from Vladimir Makarov --- I've reproduced the bug also on the trunk. The loop in question assumes a specific order for reload insns. In this case order of insns involving the reload pseudos is violated because the pseudo is also used for inheritance. We can change the loop condition to guarantee its finish independently of the reload insns order. It might results in failure of hard reg live range splitting for the pseudo. Permitting hard reg splitting for reload pseudo involved in inheritance is questionable with LRA correct work and generated code efficiency. So it has no sense for me to do this. The patch will be pushed to trunk right after finishing testing.
[Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032 --- Comment #11 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:22b0476a814a4759bb68f38b9415624a0fe52a7d commit r12-7924-g22b0476a814a4759bb68f38b9415624a0fe52a7d Author: Vladimir N. Makarov Date: Wed Mar 30 13:03:44 2022 -0400 [PR105032] LRA: modify loop condition to find reload insns for hard reg splitting When trying to split hard reg live range to assign hard reg to a reload pseudo, LRA searches for reload insns of the reload pseudo assuming a specific order of the reload insns. This order is violated if reload involved in inheritance transformation. In such case, the loop used for reload insn searching can become infinite. The patch fixes this. gcc/ChangeLog: PR middle-end/105032 * lra-assigns.cc (find_reload_regno_insns): Modify loop condition. gcc/testsuite/ChangeLog: PR middle-end/105032 * gcc.target/i386/pr105032.c: New.
[Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032 --- Comment #12 from Vladimir Makarov --- GCC-11 branch needs a bit different patch. I'll commit a modified patch to gcc-11 branch on Friday.
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 --- Comment #4 from vit9696 --- Path length limitation in the current case is 200 bytes, but in general the issue is that we would like _to be able to properly set the gcda path for the target_. Currently the specified path may not even exist when cross-compiling, and no approach to change it without prepending to the build path is simply inconvenient.
