[Bug target/104453] [9/10/11/12 Regression] ICE: SIGSEGV in handled_component_p with truncated input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104453 Richard Biener changed: What|Removed |Added Component|middle-end |target Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2022-02-09 Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Target Milestone|--- |9.5 --- Comment #1 from Richard Biener --- (gdb) p stmt $1 = (gdb) p debug_gimple_stmt (stmt) = g.0_1; ICK. Mine, I have a patch.
[Bug target/104451] [9/10/11/12 Regression] ICE: in emit_move_insn, at expr.cc:4010 with -O -mxop -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104451 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/104450] [11/12 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -O -fnon-call-exceptions -fsanitize=thread -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104450 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Richard Biener --- Hmm, OK - that needs some thoughts. I think the easiest woudl be to avoid "forwarding" the comparison if it has EH.
[Bug tree-optimization/104376] Failure to optimize clz equivalent to clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104376 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101822, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=7, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=71016 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > cond_removal_in_builtin_zero_pattern should have optimized the above but > does not for some reason. > Let me take a look. So one problem is we have: [local count: 1073741824]: if (x_3(D) == 0) goto ; [21.72%] else goto ; [78.28%] [local count: 840525097]: _1 = __builtin_clz (x_3(D)); _4 = (uint32_t) _1; [local count: 1073741824]: # _2 = PHI <32(2), _4(3)> Which we don't handle in cond_removal_in_builtin_zero_pattern, this similar to PR 7 and PR 101822, that is the code which added to fix PR 71016 is getting in the way.
[Bug middle-end/104449] [9/10/11/12 Regression] ICE: verify_gimple failed: dead statement in EH table with -fexceptions -fsanitize=address -fstack-check=generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104449 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/104448] [10/11/12 Regression] ICE: in initialize, at function-abi.cc:108 with -mavx5124vnniw / -mavx5124fmaps -mno-xsave -mabi=ms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104448
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2022-02-09
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Target Milestone|--- |10.4
--- Comment #1 from Richard Biener ---
108 gcc_assert (overlaps_hard_reg_set_p (all_clobbers, mode,
regno)
109 && overlaps_hard_reg_set_p (m_mode_clobbers[i],
110 mode, regno));
(gdb) p debug_hard_reg_set(all_clobbers)
{ 0 1 2 8 9 10 11 12 13 14 15 17 18 20 21 22 23 24 25 28 29 30 31 32 33 34 35
36 37 38 39 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73
74 75 }
$1 = void
(gdb) p regno
$2 = 44
Confirmed. Quite possibly the -mabi=ms support is incomplete here.
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 --- Comment #35 from Kewen Lin --- > I don't think the r12-6219 commit qualifies for backporting. What about the > comment#31 patch? Does it address the issue for Eigen on the branches? Got it. comment#31 patch can only address the mismatch issue on power8-fusion, it doesn't help htm. (FWIW, the previous posted patch https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587635.html doesn't either.) For htm issue, I think we can go with the workarounds for branches like: 1) target attribute "cpu=power10,htm" for callers to pretend power10 having htm to avoid mismatch. 2) adding -mno-htm for the whole Eigen build if it doesn't use any HTM features. 3) if unfortunately it does use HTM, make it fine grain to only those inlined callees with target attribute "no-htm".
[Bug rtl-optimization/104447] [9/10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104447 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104446 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/104445] [12 Regression] ICE in vect_create_partial_epilog, at tree-vect-loop.cc:5098
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104445 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Priority|P3 |P1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Meh. Mine.
[Bug tree-optimization/104444] Missing constant folding in shift expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 --- Comment #2 from Richard Biener --- Note we generally avoid "folding" undefined to anything specific, but what could trigger here is path isolation seeing if (n >= 0 && n < 32) ; else if (m >> n != 0) ... making the else path unreachable (or trap for the sake of QOI).
[Bug target/104441] [12 Regression] vzeroupper is placed at the wrong place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104441 Richard Biener changed: What|Removed |Added Priority|P2 |P1 Keywords||wrong-code Target|x86-64 |x86_64-*-* i?86-*-*
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 --- Comment #34 from Richard Biener --- (In reply to Kewen Lin from comment #33) > Since this issue affects Eigen building on Power and we have GCC11 and GCC10 > to support Power10 MMA, one of our colleagues is wondering if we can > backport all the fixes there for this PR. In my limited understanding, the > commit r12-6219 in comment 26 is more like a small feature, it might not be > recommended to be backported and we have to use some workaround for HTM. > > @Richi and @Jakub, what's your opinions? I don't think the r12-6219 commit qualifies for backporting. What about the comment#31 patch? Does it address the issue for Eigen on the branches?
[Bug c++/104379] [9/10/11 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379 --- Comment #10 from rguenther at suse dot de --- On Tue, 8 Feb 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379 > > Jakub Jelinek changed: > >What|Removed |Added > > Summary|[9/10/11/12 Regression] |[9/10/11 Regression] >|-Wshadow warning given |-Wshadow warning given >|three times |three times > > --- Comment #9 from Jakub Jelinek --- > Fixed on the trunk so far. > > Note, GCC 11 and older doesn't have the warning-control.c* infrastructure, so > all we could do there is TREE_NO_WARNING. Or warn from a place that doesn't visit this IL N times?
[Bug target/104456] New: nvptx: prevent_branch_around_nothing doesn't handle asm ("")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104456
Bug ID: 104456
Summary: nvptx: prevent_branch_around_nothing doesn't handle
asm ("")
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Testing on a GT 1030, with driver 510.x, GOMP_NVPTX_JIT=-00 and -mptx=3.1, I
run into:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_prof-version-1.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2
execution test
...
The test-case runs into the warp divergence check, because we have:
...
@ %r23 bra $L2;
$L2:
...
The prevent_branch_around_nothing is supposed to handle this, but it doesn't
trigger for 'asm ("")'.
[Bug rtl-optimization/104447] [9/10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104447
--- Comment #2 from Hongtao.liu ---
w/o -pg, there's an error output as expected:
../gcc.target/i386/pr55512-4.c:7:3: error: ‘asm’ operand has impossible
constraints
7 | asm goto ("" : : "r" (x), "r" (x + 1), "r" (x + 2), "r" (x + 3), /* {
dg-error "operand has impossible constraints" } */
It looks like an diagnostic issue?
[Bug tree-optimization/104376] Failure to optimize clz equivalent to clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104376
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> The second issue can be seen with:
> #include
>
> uint32_t countLeadingZeros32(uint32_t x)
> {
> if (x == 0)
> return 32;
> return (__builtin_clz(x)) ;
> }
cond_removal_in_builtin_zero_pattern should have optimized the above but does
not for some reason.
Let me take a look.
[Bug tree-optimization/104445] [12 Regression] ICE in vect_create_partial_epilog, at tree-vect-loop.cc:5098
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104445 Andrew Pinski changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- Most likely caused by r12-2292-g1dd3f21095858fbfd3 .
[Bug tree-optimization/104445] [12 Regression] ICE in vect_create_partial_epilog, at tree-vect-loop.cc:5098
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104445 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-02-09 Keywords||needs-bisection --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/104451] [9/10/11/12 Regression] ICE: in emit_move_insn, at expr.cc:4010 with -O -mxop -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104451 --- Comment #3 from Hongtao.liu --- ix86_expand_vector_init expects vals to be a parallel containing values of individual fields which should be either element mode of the vector mode, or a vector mode with the same element mode and smaller number of elements. But in the expander ashlv16qi3, the second operand is SImode which can't be directly passed to gen_vec_initv16qiqi. I'm testing 1 file changed, 2 insertions(+), 1 deletion(-) gcc/config/i386/sse.md | 3 ++- modified gcc/config/i386/sse.md @@ -24153,8 +24153,9 @@ (define_expand "3" negate = true; } par = gen_rtx_PARALLEL (V16QImode, rtvec_alloc (16)); + tmp = lowpart_subreg (QImode, operands[2], SImode); for (i = 0; i < 16; i++) -XVECEXP (par, 0, i) = operands[2]; +XVECEXP (par, 0, i) = tmp; tmp = gen_reg_rtx (V16QImode); emit_insn (gen_vec_initv16qiqi (tmp, par));
[Bug target/104451] [9/10/11/12 Regression] ICE: in emit_move_insn, at expr.cc:4010 with -O -mxop -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104451 --- Comment #2 from Hongtao.liu --- -mavx512f is not necessary, PR can be produced by -mxop -O -mavx2
[Bug rtl-optimization/104438] Combine optimization opportunity exposed after pro_and_epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104438 --- Comment #5 from Hongtao.liu --- (In reply to Hongtao.liu from comment #4) > > It is unclear why the CFG wasn't straightened out here. Is the bb commented > > as "asm" actually asm? Then GCC will not see it is very cheap/small, yeah. > > "asm" is not inline assembly. it's BB 6 below > > (note 89 88 126 6 [bb 6] NOTE_INSN_BASIC_BLOCK) > (call_insn 126 89 121 6 (parallel [ > (call (mem:QI (const_int 0 [0]) [0 S1 A8]) > (const_int 0 [0])) > (unspec [ > (const_int 1 [0x1]) > ] UNSPEC_CALLEE_ABI) > ]) -1 > (expr_list:REG_EH_REGION (const_int -2147483648 [0x8000]) > (nil)) > (nil)) According to PR104441, vzeroupper shouldn't be inserted here, after fix of PR104441, CFG wasn't straightened.
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 Kewen Lin changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #33 from Kewen Lin --- Since this issue affects Eigen building on Power and we have GCC11 and GCC10 to support Power10 MMA, one of our colleagues is wondering if we can backport all the fixes there for this PR. In my limited understanding, the commit r12-6219 in comment 26 is more like a small feature, it might not be recommended to be backported and we have to use some workaround for HTM. @Richi and @Jakub, what's your opinions?
[Bug rtl-optimization/104438] Combine optimization opportunity exposed after pro_and_epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104438
--- Comment #4 from Hongtao.liu ---
> It is unclear why the CFG wasn't straightened out here. Is the bb commented
> as "asm" actually asm? Then GCC will not see it is very cheap/small, yeah.
"asm" is not inline assembly. it's BB 6 below
(note 89 88 126 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(call_insn 126 89 121 6 (parallel [
(call (mem:QI (const_int 0 [0]) [0 S1 A8])
(const_int 0 [0]))
(unspec [
(const_int 1 [0x1])
] UNSPEC_CALLEE_ABI)
]) -1
(expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil))
(nil))
(jump_insn 121 126 122 6 (set (pc)
(label_ref 91)) 892 {jump}
(nil)
-> 91)
(barrier 122 121 112)
(code_label 112 122 111 7 4 (nil) [1 uses])
(note 111 112 11 7 [bb 7] NOTE_INSN_BASIC_BLOCK)
(insn 11 111 12 7 (set (reg:V8SI 20 xmm0 [orig:131 _168 ] [131])
(const_vector:V8SI [
(const_int 0 [0]) repeated x8
])) "test.c":28:19 1696 {movv8si_internal}
(nil))
(insn 12 11 91 7 (set (reg/v:V4DI 23 xmm3 [orig:87 ymm ] [87])
(const_vector:V4DI [
(const_int 0 [0]) repeated x4
])) "test.c":24:19 1699 {movv4di_internal}
(nil))
(code_label 91 12 92 8 2 (nil) [1 uses])
(note 92 91 94 8 [bb 8] NOTE_INSN_BASIC_BLOCK)
(insn 94 92 99 8 (set (reg:V2DI 23 xmm3 [176])
(vec_select:V2DI (reg/v:V4DI 23 xmm3 [orig:87 ymm ] [87])
(parallel [
(const_int 2 [0x2])
(const_int 3 [0x3])
]))) "{vec_extract_hi_v4di}
(nil))
(insn 99 94 127 8 (set (reg:V4SI 20 xmm0 [180])
(plus:V4SI (reg:V4SI 20 xmm0 [178])
(reg:V4SI 23 xmm3 [176]))) " {*addv4si3}
(nil))
(insn 127 99 107 8 (set (reg:SI 0 ax [181])
(reg:SI 20 xmm0 [180])) " {*movsi_internal}
(nil))
(insn 107 127 123 8 (use (reg/i:SI 0 ax)) "test.c":40:1 -1
(nil))
(note 123 107 0 NOTE_INSN_DELETED)
[Bug analyzer/104452] [12 Regression] ICE: in hashtab_chk_error, at hash-table.cc:137 with -O -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104452 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/101081] analyzer testsuite failures seen with new glibc due to malloc attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101081 --- Comment #3 from David Malcolm --- Thanks. The above patch fixes part (a) of comment #0, but I'm not yet sure what to do about part (b), so keeping this bug report open for now.
[Bug analyzer/101081] analyzer testsuite failures seen with new glibc due to malloc attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101081 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:e52a683170877d140eebc9782731eaf11897db71 commit r12-7119-ge52a683170877d140eebc9782731eaf11897db71 Author: Joel Teichroeb Date: Fri Feb 4 11:35:08 2022 -0500 analyzer: Fix tests for glibc 2.35 [PR101081] In recent versions of glibc fopen has __attribute__((malloc)). Since we can not detect wether this attribute is present or not, we avoid including stdio.h and instead forward declare what we need in each test. Signed-off-by: Joel Teichroeb gcc/testsuite/ChangeLog: PR analyzer/101081 * gcc.dg/analyzer/analyzer-verbosity-2a.c: Replace #include of stdio.h with declarations needed by the test. * gcc.dg/analyzer/analyzer-verbosity-3a.c: Likewise. * gcc.dg/analyzer/edges-1.c: Likewise. * gcc.dg/analyzer/file-1.c: Likewise. * gcc.dg/analyzer/file-2.c: Likewise. * gcc.dg/analyzer/file-paths-1.c: Likewise. * gcc.dg/analyzer/file-pr58237.c: Likewise. * gcc.dg/analyzer/pr99716-1.c: Likewise. Signed-off-by: David Malcolm
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 --- Comment #32 from Kewen Lin --- (In reply to Michael Meissner from comment #31) > Created attachment 52383 [details] > Simpler patch to fix the problem with power8-fusion. > > This patch just ignores the -mpower8-fusion option in the callee if the > caller does not have it set, and the option wasn't set explicitly. Thanks for the patch Mike! IMHO, it can also remove the option -mno-power8-fusion in gcc/testsuite/gcc.dg/lto/pr102059-1_0.c, the case is designed for the usage reflected by this PR.
[Bug analyzer/104452] [12 Regression] ICE: in hashtab_chk_error, at hash-table.cc:137 with -O -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104452 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:391512ade5f6cda95456133296c8dcc42d5fbefd commit r12-7118-g391512ade5f6cda95456133296c8dcc42d5fbefd Author: David Malcolm Date: Tue Feb 8 16:37:08 2022 -0500 analyzer: fix hashing of bit_range_region::key_t [PR104452] gcc/analyzer/ChangeLog: PR analyzer/104452 * region-model.cc (selftest::test_bit_range_regions): New. (selftest::analyzer_region_model_cc_tests): Call it. * region.h (bit_range_region::key_t::hash): Fix hashing of m_bits to avoid using uninitialized data. gcc/testsuite/ChangeLog: PR analyzer/104452 * gcc.dg/analyzer/pr104452.c: New test. Signed-off-by: David Malcolm
[Bug c++/103752] [12 Regression][ICE][modules] with import
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103752 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Last reconfirmed||2022-02-09 CC||jason at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug c++/96876] missing check for destructibility of base classes in aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96876 Jason Merrill changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jason Merrill --- Fixed for GCC 12.
[Bug c++/96876] missing check for destructibility of base classes in aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96876 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:53cac72cf0821217f99d0640ba72cc2999ec7dc0 commit r12-7117-g53cac72cf0821217f99d0640ba72cc2999ec7dc0 Author: Jason Merrill Date: Fri Feb 4 18:25:51 2022 -0500 c++: cleanup constant-init'd members [PR96876] This is a case missed by my recent fixes to aggregate initialization and exception cleanup for PR94041 et al: we also need to clean up members with constant initialization if initialization of a later member throws. It also occurs to me that we needn't bother building the cleanups if -fno-exceptions; build_vec_init already doesn't. PR c++/96876 gcc/cp/ChangeLog: * typeck2.cc (split_nonconstant_init_1): Push cleanups for preceding members with constant initialization. (maybe_push_temp_cleanup): Do nothing if -fno-exceptions. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/aggr-base11.C: New test. * g++.dg/eh/aggregate2.C: New test.
[Bug rtl-optimization/104447] [9/10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104447
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-02-09
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Known to work||7.5.0
Target Milestone|--- |9.5
Known to fail||8.1.0
--- Comment #1 from Andrew Pinski ---
Confirmed.
note The ICE changed in GCC 11 from:
:3:3: error: 'asm' operand has impossible constraints
3 | asm goto ("" : : "r" (x), "r" (x + 1), "r" (x + 2), "r" (x + 3), /* {
dg-error "operand has impossible constraints" } */
| ^~~
:3:3: error: 'asm' operand has impossible constraints
:10:1: error: in basic block 2:
10 | }
| ^
:10:1: error: in basic block 2:
}
^
:10:1: error: flow control insn inside a basic block
(jump_insn 23 77 75 2 (parallel [
(asm_operands/v ("") ("") 0 []
[]
[
(label_ref:DI 24)
] :3)
(clobber (reg:CCFP 18 fpsr))
(clobber (reg:CC 17 flags))
]) "":3 -1
(nil)
-> 24)
To:
:10:1: internal compiler error: maximum number of LRA assignment passes
is achieved (30)
So it would be useful to get the bisects at the point of change and also when
it originally broke.
[Bug tree-optimization/104450] [11/12 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -O -fnon-call-exceptions -fsanitize=thread -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104450
Andrew Pinski changed:
What|Removed |Added
Target Milestone|12.0|11.3
Summary|[12 Regression] ICE:|[11/12 Regression] ICE:
|verify_flow_info failed: BB |verify_flow_info failed: BB
|2 cannot throw but has an |2 cannot throw but has an
|EH edge with -O |EH edge with -O
|-fnon-call-exceptions |-fnon-call-exceptions
|-fsanitize=thread -mavx512f |-fsanitize=thread -mavx512f
Known to fail||11.1.0, 11.2.0
Keywords||needs-bisection
Known to work||10.1.0, 9.1.0
--- Comment #2 from Andrew Pinski ---
Note GCC 10 and before did:
_5 = VEC_COND_EXPR = { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 }, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1 }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>;
Which is marked as maybe throwing.
[Bug libstdc++/104442] atomic::wait incorrectly loops in case of spurious notification when __waiter is shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104442 Thomas Rodgers changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-02-09 CC||rodgertq at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Thomas Rodgers --- I took a look at whether or not it made sense to do a different refactoring with this version of the implementation and I don't believe that it does (the implementation detail here is likely to change substantially when we commit to an ABI stable version) and indeed, the predicate version does exactly what this patch proposes.
[Bug c++/104455] New: Cannot select -march=armv7-a using GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104455 Bug ID: 104455 Summary: Cannot select -march=armv7-a using GCC 11 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: noloader at gmail dot com Target Milestone: --- Hi Everyone, We are trying to fix a compile problem Debian encountered on Sid [1,2]. The machine is armhf, but I don't have access to it. Sid is using GCC 11, but I am not sure which version. The problem does not exist in GCC 10 and below. I think this is the test case. Below, test.S is mostly armv4 but has some armv7 instructions. I used movw and movt as an example since they are armv7. $ cat test.S .globl return_magic .type return_magic,%function return_magic: movw r0, #0x1234 movt r0, #0x5678 bl 0 $ g++ -g2 -O3 -Wa,--noexecstack -march=armv7-a test.S -c When Debian compiles with GCC 11, it results in: cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU test.S does not use floating point or neon instructions. This source file does not need a fpu. We don't care what the platform default is because we don't use it. But in this case, the machine is armhf so GCC should know it should use hard floats. When I attempt to add -mfpu=auto per [3], it results in another error: cc1: sorry, unimplemented: -mfpu=auto not currently supported without an explicit CPU. cc1: error: -mfloat-abi=hard: selected processor lacks an FPU test.S does not use floating point or neon instructions. This source file does not need a fpu. I also tried -mfpu=none, but it results in: g++: error: unrecognized argument in option ‘-mfpu=none’ g++: note: valid arguments to ‘-mfpu=’ are: auto crypto-neon-fp-armv8 fp-armv8 fpv4-sp-d16 fpv5-d16 fpv5-sp-d16 neon neon-fp-armv8 neon-fp16 neon-vfpv3 neon-vfpv4 vfp vfp3 vfpv2 vfpv3 vfpv3-d16 vfpv3-d16-fp16 vfpv3-fp16 vfpv3xd vfpv3xd-fp16 vfpv4 vfpv4-d16; did you mean ‘neon’? In the past we avoided specifying a -mfpu option because the code [used to] work with GCC 4 and above, Clang 3 and above, armel, armhf and Android with soft floats. The compiler always knew what float abi it should use. I would like to drop -march=armv7-a, but GCC requires me to use an ISA option before I use instructions from the ISA. I've never liked the rule, but it is what it is. (Microsoft's C/C++ compiler got this right). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001995 [2] https://github.com/weidai11/cryptopp/issues/1094 [3] https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
[Bug tree-optimization/104420] [12 Regression] Inconsistent checks for X * 0.0 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104420 Roger Sayle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com CC||roger at nextmovesoftware dot com --- Comment #2 from Roger Sayle --- Patch proposed https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590049.html
[Bug analyzer/104452] [12 Regression] ICE: in hashtab_chk_error, at hash-table.cc:137 with -O -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104452 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug analyzer/104452] [12 Regression] ICE: in hashtab_chk_error, at hash-table.cc:137 with -O -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104452 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-02-08 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Thanks for filing this; I'm testing a fix.
[Bug middle-end/98900] misleading -Wuninitialized using a variable outside its lifetime with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98900
--- Comment #3 from Martin Sebor ---
GCC 12 issues -Wdangling-poinnter for this bug now at all optimization levels.
It still issues -Wuninitialized at -O1 and above, but with the dangling pointer
warning I don't think it's a big deal. It should of course still be possible
to suppress it.
$ cat pr98900.c && gcc -S -Wall pr98900.c
int g = 10;
int main()
{
int* p = 0;
{
int x = 15;
p = &x;
}
g = *p;
return 0;
}
pr98900.c: In function ‘main’:
pr98900.c:11:9: warning: using dangling pointer ‘p’ to ‘x’
[-Wdangling-pointer=]
11 | g = *p;
| ^~
pr98900.c:7:13: note: ‘x’ declared here
7 | int x = 15;
| ^
[Bug target/104451] [9/10/11/12 Regression] ICE: in emit_move_insn, at expr.cc:4010 with -O -mxop -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104451 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Ever confirmed|0 |1 Last reconfirmed||2022-02-08 Summary|ICE: in emit_move_insn, at |[9/10/11/12 Regression] |expr.cc:4010 with -O -mxop |ICE: in emit_move_insn, at |-mavx512f |expr.cc:4010 with -O -mxop ||-mavx512f Status|UNCONFIRMED |NEW Target Milestone|--- |9.5 Known to work||4.9.0, 4.9.4 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug middle-end/104077] bogus/missing -Wdangling-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077 Bug 104077 depends on bug 81524, which changed state. Bug 81524 Summary: Bogus or missing warnings when dereferencing pointer to deallocated stack memory https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c/81524] Bogus or missing warnings when dereferencing pointer to deallocated stack memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Status|NEW |RESOLVED
Target Milestone|--- |12.0
Resolution|--- |FIXED
Blocks||104077
--- Comment #6 from Martin Sebor ---
As far as I can see this works as requested without sanitization in GCC 12:
$ (set -x; for p in PARAM RETURN BLOCK; do for m in READ WRITE; do gcc
-DTEST_${p}_$m -S -Wall pr81524.c; done; done)
+ for p in PARAM RETURN BLOCK
+ for m in READ WRITE
+ gcc -DTEST_PARAM_READ -S -Wall pr81524.c
pr81524.c: In function ‘test_param_local’:
pr81524.c:33:7: warning: storing the address of local variable ‘local’ in ‘*pp’
[-Wdangling-pointer=]
33 | *pp = &local;
| ^~~~
pr81524.c:32:7: note: ‘local’ declared here
32 | int local = 1;
| ^
pr81524.c:32:7: note: ‘pp’ declared here
+ for m in READ WRITE
+ gcc -DTEST_PARAM_WRITE -S -Wall pr81524.c
pr81524.c: In function ‘test_param_local’:
pr81524.c:33:7: warning: storing the address of local variable ‘local’ in ‘*pp’
[-Wdangling-pointer=]
33 | *pp = &local;
| ^~~~
pr81524.c:32:7: note: ‘local’ declared here
32 | int local = 1;
| ^
pr81524.c:32:7: note: ‘pp’ declared here
+ for p in PARAM RETURN BLOCK
+ for m in READ WRITE
+ gcc -DTEST_RETURN_READ -S -Wall pr81524.c
pr81524.c: In function ‘test_return_local’:
pr81524.c:42:10: warning: function returns address of local variable
[-Wreturn-local-addr]
42 | return &local;
| ^~
+ for m in READ WRITE
+ gcc -DTEST_RETURN_WRITE -S -Wall pr81524.c
pr81524.c: In function ‘test_return_local’:
pr81524.c:42:10: warning: function returns address of local variable
[-Wreturn-local-addr]
42 | return &local;
| ^~
+ for p in PARAM RETURN BLOCK
+ for m in READ WRITE
+ gcc -DTEST_BLOCK_READ -S -Wall pr81524.c
pr81524.c: In function ‘main’:
pr81524.c:88:10: warning: using dangling pointer ‘p’ to ‘local’
[-Wdangling-pointer=]
88 | return *p;
| ^~
pr81524.c:76:9: note: ‘local’ declared here
76 | int local = 1;
| ^
pr81524.c:81:3: warning: using dangling pointer ‘p’ to ‘local’
[-Wdangling-pointer=]
81 | printf("%d\n", *p);
| ^~
pr81524.c:76:9: note: ‘local’ declared here
76 | int local = 1;
| ^
+ for m in READ WRITE
+ gcc -DTEST_BLOCK_WRITE -S -Wall pr81524.c
pr81524.c: In function ‘main’:
pr81524.c:88:10: warning: using dangling pointer ‘p’ to ‘local’
[-Wdangling-pointer=]
88 | return *p;
| ^~
pr81524.c:76:9: note: ‘local’ declared here
76 | int local = 1;
| ^
pr81524.c:84:6: warning: using dangling pointer ‘p’ to ‘local’
[-Wdangling-pointer=]
84 | *p = 1;
| ~~~^~~
pr81524.c:76:9: note: ‘local’ declared here
76 | int local = 1;
| ^
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077
[Bug 104077] bogus/missing -Wdangling-pointer
[Bug fortran/93482] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93482 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|NEW |WAITING --- Comment #3 from anlauf at gcc dot gnu.org --- Seems to have been fixed on mainline, and backported to 11- and 10-branch. Likely a duplicate.
[Bug middle-end/104355] Misleading -Warray-bounds documentation says "always out of bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104355 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Martin Sebor --- Let me update the manual.
[Bug middle-end/104355] Misleading -Warray-bounds documentation says "always out of bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104355
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #2 from Martin Sebor ---
The documentation is also incorrect about the warning being only active with
-ftree-vrp. A small subset of -Warray-bounds is issued even without
optimization. For example the following warning(s) have been issued since GCC
4.1:
$ cat a.c && gcc -S -Wall a.c
int f (void)
{
return __builtin_strlen ("123" + 5);
}
a.c: In function ‘f’:
a.c:3:34: warning: offset ‘5’ outside bounds of constant string
[-Warray-bounds]
3 | return __builtin_strlen ("123" + 5);
|~~^~~
a.c:3:10: warning: offset ‘5’ outside bounds of constant string
[-Warray-bounds]
3 | return __builtin_strlen ("123" + 5);
| ^~~~
[Bug middle-end/104436] [12 Regression] spurious -Wdangling-pointer assigning local address to a class passed by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104436 Martin Sebor changed: What|Removed |Added Target Milestone|--- |12.0 Summary|spurious -Wdangling-pointer |[12 Regression] spurious |assigning local address to |-Wdangling-pointer |a class passed by value |assigning local address to ||a class passed by value Keywords||patch --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590046.html
[Bug tree-optimization/104444] Missing constant folding in shift expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-02-08
--- Comment #1 from Andrew Pinski ---
Confirmed:
int g(unsigned n) {
return ((0xff) >> n) != 0;
}
So the general case is:
(simplify
(neeq (lshift INTEGER_CST@0 @1) zero_p)
(ltge (@1 {bitsizeoftype(@1) - wi::clz(@0);}))
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 --- Comment #31 from Michael Meissner --- Created attachment 52383 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52383&action=edit Simpler patch to fix the problem with power8-fusion. This patch just ignores the -mpower8-fusion option in the callee if the caller does not have it set, and the option wasn't set explicitly.
[Bug libstdc++/104454] New: filesystem::canonical needs to strip trailing slash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104454
Bug ID: 104454
Summary: filesystem::canonical needs to strip trailing slash
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Keywords: testsuite-fail
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
27_io/filesystem/operations/canonical.cc FAILs on AIX because the result of
realpath("foo/.", 0) is "foo/" whereas on Linux it's "foo".
For consistency across platforms, filesystem::canonical should remove that
trailing slash.
27_io/filesystem/operations/weakly_canonical.cc also FAILs on AIX, probably for
the same reason.
[Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104446
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Known to fail||11.2.0, 9.1.0
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-02-08
Known to work||8.1.0
Target Milestone|--- |9.5
Ever confirmed|0 |1
Component|c |middle-end
--- Comment #1 from Andrew Pinski ---
Confirmed reduced testcase w/o -finstrument-functions:
That is only -O2 -m32 -mrtd is needed to produce the ICE.
register volatile int a __asm__("%esp");
void f(void*);
void f1(void*);
void t ()
{
f(__builtin_return_address(0));
a = 0;
f1(__builtin_return_address(0));
}
CUT ---
Note this works with the C++ front-end for some reason.
[Bug middle-end/104449] [9/10/11/12 Regression] ICE: verify_gimple failed: dead statement in EH table with -fexceptions -fsanitize=address -fstack-check=generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104449 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |9.5 Ever confirmed|0 |1 Last reconfirmed||2022-02-08 --- Comment #1 from Andrew Pinski --- Confirmed. With -fstack-check=generic, __builtin_alloca_with_align is marked as being able to throw but asan decides to insert its annonations right after the builtin call instead of on the branch after the function call.
[Bug tree-optimization/104450] [12 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -O -fnon-call-exceptions -fsanitize=thread -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104450
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-02-08
--- Comment #1 from Andrew Pinski ---
Here is a testcase without -fsanitize=thread:
That is you just need -O1 -fnon-call-exceptions -mavx512f:
#define vectsize 64
typedef int __attribute__((__vector_size__ (vectsize))) V;
typedef float __attribute__((__vector_size__ (vectsize))) F;
F f;
V v;
struct g{~g();};
void
foo (void)
{
g t;
v += (V) (0 <= f);
}
- CUT
We start out with (the comparison throws):
f.0_1 = f;
_6 = f.0_1 >= { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0 };
[local count: 1073741824]:
_2 = VEC_COND_EXPR <_6, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1 }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>;
v.1_3 = v;
And isel converts it into:
f.0_1 = f;
[local count: 1073741824]:
_2 = .VCOND (f.0_1, { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0, 0.0 }, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1 }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, 111);
But now the comparison and VEC_COND_EXPR is just the builtin .VCOND which is
not marked to throw and in bb3
[Bug middle-end/104453] New: [9/10/11/12 Regression] ICE: SIGSEGV in handled_component_p with truncated input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104453 Bug ID: 104453 Summary: [9/10/11/12 Regression] ICE: SIGSEGV in handled_component_p with truncated input Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 52382 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52382&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -mavx512f testcase.c -wrapper valgrind,-q testcase.c: In function 'foo': testcase.c:7:33: error: expected ')' at end of input 7 | __builtin_ia32_psrawi256 (g, 0 |~^ | ) testcase.c:7:3: error: expected declaration or statement at end of input 7 | __builtin_ia32_psrawi256 (g, 0 | ^~~~ ==13315== Invalid read of size 2 ==13315==at 0x1062CC4: handled_component_p (tree.h:5069) ==13315==by 0x1062CC4: get_base_loadstore(tree_node*) (gimple-walk.cc:732) ==13315==by 0x1063B70: walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*, tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*, void*)) (gimple-walk.cc:765) ==13315==by 0xEA8CBA: record_stmt_references (cgraphbuild.cc:263) ==13315==by 0xEA8CBA: (anonymous namespace)::pass_build_cgraph_edges::execute(function*) (cgraphbuild.cc:330) ==13315==by 0x127E0DA: execute_one_pass(opt_pass*) (passes.cc:2637) ==13315==by 0x127E99F: execute_pass_list_1(opt_pass*) (passes.cc:2737) ==13315==by 0x127E9D8: execute_pass_list(function*, opt_pass*) (passes.cc:2748) ==13315==by 0xEAB0FB: cgraph_node::analyze() (cgraphunit.cc:685) ==13315==by 0xEADF97: analyze_functions(bool) (cgraphunit.cc:1240) ==13315==by 0xEAEC2D: symbol_table::finalize_compilation_unit() (cgraphunit.cc:2500) ==13315==by 0x1386F3F: compile_file() (toplev.cc:479) ==13315==by 0xCF54E8: do_compile (toplev.cc:2158) ==13315==by 0xCF54E8: toplev::main(int, char**) (toplev.cc:2310) ==13315==by 0xCF6C0A: main (main.cc:39) ==13315== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==13315== during GIMPLE pass: *build_cgraph_edges testcase.c:5:1: internal compiler error: Segmentation fault 5 | foo (void) | ^~~ 0x1386c7f crash_signal /repo/gcc-trunk/gcc/toplev.cc:322 0x1062cc4 handled_component_p /repo/gcc-trunk/gcc/tree.h:5069 0x1062cc4 get_base_loadstore /repo/gcc-trunk/gcc/gimple-walk.cc:732 0x1063b70 walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*, tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*, void*)) /repo/gcc-trunk/gcc/gimple-walk.cc:765 0xea8cba cgraph_node::record_stmt_references(gimple*) /repo/gcc-trunk/gcc/cgraphbuild.cc:263 0xea8cba execute /repo/gcc-trunk/gcc/cgraphbuild.cc:330 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7089-20220208123931-g0103c2e4082-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-7089-20220208123931-g0103c2e4082-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220208 (experimental) (GCC)
[Bug tree-optimization/104450] [12 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -O -fnon-call-exceptions -fsanitize=thread -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104450 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Component|middle-end |tree-optimization
[Bug tree-optimization/104165] [12 Regression] -Warray-bounds for unreachable code inlined from std::sort()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165
Martin Sebor changed:
What|Removed |Added
URL||https://bugzilla.redhat.com
||/show_bug.cgi?id=2051783
Keywords||missed-optimization
--- Comment #2 from Martin Sebor ---
See also another similar test case reduced in
https://bugzilla.redhat.com/show_bug.cgi?id=2051783:
#include
bool cond;
int foo;
int func (void)
{
int a[3], qa = 0;
for(int i = 0; i < 3; i++)
if (cond)
a[qa++] = foo;
std::sort (a, a + qa);
return 0;
}
The warning is issued for the synthesized call to std::__insertion_sort.isra()
in basic block 9 (vrp1 output):
[local count: 71766220]:
std::__insertion_sort.isra (&a, &MEM [(void *)&a + 64B]); <<<
-Warray-bounds
goto ; [100.00%]
The block is unreachable but GCC is unable to determine that from the loop.
Adding an annotation just after the loop asserting that avoids the warning and
also improves the emitted object code.
The same warning triggers in GCC 11 with -Wsystem-headers. The difference in
GCC 12 is that -Wsystem-headers no longer disables warnings for code defined in
system headers that's inlined into user code.
[Bug analyzer/104452] New: [12 Regression] ICE: in hashtab_chk_error, at hash-table.cc:137 with -O -fanalyzer
,-q,--track-origins=yes ==30624== Use of uninitialised value of size 8 ==30624==at 0x17634FE: is_empty, ana::bit_range_region*> >::hash_entry> (hash-map-traits.h:73) ==30624==by 0x17634FE: is_empty (hash-map.h:71) ==30624==by 0x17634FE: is_empty (hash-table.h:541) ==30624==by 0x17634FE: find_with_hash (hash-table.h:925) ==30624==by 0x17634FE: get (hash-map.h:189) ==30624==by 0x17634FE: get (analyzer.h:371) ==30624==by 0x17634FE: ana::region_model_manager::get_bit_range(ana::region const*, tree_node*, ana::bit_range const&) (region-model-manager.cc:1507) ==30624==by 0x1740F54: ana::region_model::get_lvalue_1(ana::path_var, ana::region_model_context*) const (region-model.cc:1724) ==30624==by 0x17410D9: get_lvalue (region-model.cc:1818) ==30624==by 0x17410D9: ana::region_model::get_lvalue(tree_node*, ana::region_model_context*) const (region-model.cc:1829) ==30624==by 0x17416E0: get_region_for_poisoned_expr (region-model.cc:886) ==30624==by 0x17416E0: ana::region_model::check_for_poison(ana::svalue const*, tree_node*, ana::region_model_context*) const (region-model.cc:855) ==30624==by 0x1746B5C: ana::region_model::on_assignment(gassign const*, ana::region_model_context*) (region-model.cc:903) ==30624==by 0x171F498: ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode const*, gimple const*, ana::program_state*, ana::uncertainty_t*, ana::path_context*) (engine.cc:1305) ==30624==by 0x172269D: ana::exploded_graph::process_node(ana::exploded_node*) (engine.cc:3694) ==30624==by 0x1723682: ana::exploded_graph::process_worklist() (engine.cc:3137) ==30624==by 0x1725B86: ana::impl_run_checkers(ana::logger*) (engine.cc:5716) ==30624==by 0x17269FE: ana::run_checkers() (engine.cc:5787) ==30624==by 0x1715F98: (anonymous namespace)::pass_analyzer::execute(function*) (analyzer-pass.cc:87) ==30624==by 0x127E0DA: execute_one_pass(opt_pass*) (passes.cc:2637) ==30624== Uninitialised value was created by a stack allocation ==30624==at 0x1740A89: ana::region_model::get_lvalue_1(ana::path_var, ana::region_model_context*) const (region-model.cc:1690) ==30624== ==30624== Use of uninitialised value of size 8 ... $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7089-20220208123931-g0103c2e4082-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-7089-20220208123931-g0103c2e4082-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220208 (experimental) (GCC)
[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568 --- Comment #11 from Jonathan Wakely --- (In reply to palmer from comment #10) > After signing off last night I realized that none of that would work anyway, > though, as even with the same library on both ends users would end up with a > different mutex and thus races. So I think that one isn't worth worrying > about. Agreed. > I'm not > sure if folks are shipping clang-built libstdc++ anywhere (and if so, are They're not, and it's unsupported. Libstdc++ is part of GCC and must be built by GCC. > I guess I'm not really sure here: normally I'd say we're stuck with the > default being ABI compatible, but I don't know the rules in libstdc++. I'm > assuming that forcing the default to be mutex could still allow users who > want atomic to configure with --with-libstdcxx-lock-policy=atomic, so at Yup. > least there's a path forward. IIUC users will get link errors when moving > between the two flavors (the explicit template instantiations will have > different integer values), Not necessarily. The std::shared_ptr type isn't affected by that template parameter, only its base class is. So APIs defined in terms of the public std::shared_ptr type do not get linker errors if the private std::__shared_ptr type differs.
[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #11 from Hannes Hauswedell ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Hannes Hauswedell from comment #8)
> > Hi, I wanted to ask politely whether you have discussed this issue and came
> > to a conclusion?
>
> No, because the current priority is gcc 12.
I just realised that the issue was actually not that old, sorry for bugging
you! Looking forward to GCC12 :)
(In reply to Jonathan Wakely from comment #10)
> I think we should backport it except for the removal of the default
> constructors for {back_,front_,}insert_iterator, ostream_iterator and
> basic_istream_view. If we keep those default constructible on the release
> branches I think the chance of breaking any code is minimal.
That's sounds like a good plan :+1:
[Bug tree-optimization/104445] [12 Regression] ICE in vect_create_partial_epilog, at tree-vect-loop.cc:5098
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104445 Andrew Pinski changed: What|Removed |Added Component|c |tree-optimization Target Milestone|--- |12.0
[Bug target/104451] New: ICE: in emit_move_insn, at expr.cc:4010 with -O -mxop -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104451 Bug ID: 104451 Summary: ICE: in emit_move_insn, at expr.cc:4010 with -O -mxop -mavx512f Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 52380 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52380&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -mxop -mavx512f testcase.c during RTL pass: expand testcase.c: In function 'foo': testcase.c:7:12: internal compiler error: in emit_move_insn, at expr.cc:4010 7 | return v << c; | ~~^~~~ 0x6ca000 emit_move_insn(rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/expr.cc:4010 0xf7c505 force_reg(machine_mode, rtx_def*) /repo/gcc-trunk/gcc/explow.cc:688 0x17a8aba ix86_vector_duplicate_value /repo/gcc-trunk/gcc/config/i386/i386-expand.cc:14768 0x17d00f2 ix86_expand_vector_init(bool, rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/config/i386/i386-expand.cc:15888 0x1e76e71 gen_vec_initv64qiqi(rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/config/i386/sse.md:25960 0x1e76e71 gen_ashlv16qi3(rtx_def*, rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/config/i386/sse.md:24160 0x1240ffe expand_binop_directly /repo/gcc-trunk/gcc/optabs.cc:1442 0x123ea21 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) /repo/gcc-trunk/gcc/optabs.cc:1529 0xf81954 expand_shift_1 /repo/gcc-trunk/gcc/expmed.cc:2661 0xf89083 expand_variable_shift(tree_code, machine_mode, rtx_def*, tree_node*, rtx_def*, int) /repo/gcc-trunk/gcc/expmed.cc:2713 0xf9c3bd expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /repo/gcc-trunk/gcc/expr.cc:9931 0xfa2ce7 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /repo/gcc-trunk/gcc/expr.cc:10504 0xe6709c expand_expr /repo/gcc-trunk/gcc/expr.h:301 0xe6709c expand_return /repo/gcc-trunk/gcc/cfgexpand.cc:3793 0xe6709c expand_gimple_stmt_1 /repo/gcc-trunk/gcc/cfgexpand.cc:3902 0xe6709c expand_gimple_stmt /repo/gcc-trunk/gcc/cfgexpand.cc:4028 0xe6cd8e expand_gimple_basic_block /repo/gcc-trunk/gcc/cfgexpand.cc:6069 0xe6e987 execute /repo/gcc-trunk/gcc/cfgexpand.cc:6795 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7089-20220208123931-g0103c2e4082-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-7089-20220208123931-g0103c2e4082-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220208 (experimental) (GCC)
[Bug middle-end/104450] New: [12 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -O -fnon-call-exceptions -fsanitize=thread -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104450 Bug ID: 104450 Summary: [12 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -O -fnon-call-exceptions -fsanitize=thread -mavx512f Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 52379 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52379&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -fnon-call-exceptions -fsanitize=thread -mavx512f testcase.c testcase.c: In function 'foo': testcase.c:8:1: error: BB 2 cannot throw but has an EH edge 8 | foo (void) | ^~~ during GIMPLE pass: isel testcase.c:8:1: internal compiler error: verify_flow_info failed 0xe7189e verify_flow_info() /repo/gcc-trunk/gcc/cfghooks.cc:284 0x127adea execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2096 0x127b2fe execute_todo /repo/gcc-trunk/gcc/passes.cc:2138 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7089-20220208123931-g0103c2e4082-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-7089-20220208123931-g0103c2e4082-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220208 (experimental) (GCC)
[Bug middle-end/104449] New: [9/10/11/12 Regression] ICE: verify_gimple failed: dead statement in EH table with -fexceptions -fsanitize=address -fstack-check=generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104449 Bug ID: 104449 Summary: [9/10/11/12 Regression] ICE: verify_gimple failed: dead statement in EH table with -fexceptions -fsanitize=address -fstack-check=generic Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 52378 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52378&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -fexceptions -fsanitize=address -fstack-check=generic testcase.c testcase.c: In function 'foo': testcase.c:2:1: error: dead statement in EH table 2 | foo (void) | ^~~ # _4 = VDEF <.MEM_2> _5 = __builtin_alloca_with_align (64, 32); during GIMPLE pass: asan0 testcase.c:2:1: internal compiler error: verify_gimple failed 0x13d156d verify_gimple_in_cfg(function*, bool) /repo/gcc-trunk/gcc/tree-cfg.cc:5561 0x127adc7 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2084 0x127b2fe execute_todo /repo/gcc-trunk/gcc/passes.cc:2138 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7089-20220208123931-g0103c2e4082-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-7089-20220208123931-g0103c2e4082-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220208 (experimental) (GCC)
[Bug target/104422] nvptx: for-3.exe fail with driver 390.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104422 --- Comment #6 from Tom de Vries --- (In reply to Tom de Vries from comment #5) > Still on GT1030, does not reproduce with 470.x, neither the minimal nor the > complete for-3.c. And the same for 510.x. So, I'm parking this for now. This may well be the umul bug that nvidia decided it didn't want to fix on the 390.x driver branch. It may be something else, but we'll only known after reducing the test-case at ptx level, which might be difficult and time-intensive for an openmp test-case.
[Bug rtl-optimization/104153] [12 Regression] ICE due to recent ifcvt changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153 --- Comment #10 from CVS Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:d0d4601ccde3c4849f6e7244035f1a899d608cb7 commit r12-7114-gd0d4601ccde3c4849f6e7244035f1a899d608cb7 Author: Robin Dapp Date: Tue Feb 8 16:11:20 2022 +0100 ifcvt: Fix PR104153 and PR104198. This is a bugfix for r12-6747-gaa8cfe785953a0 which caused an ICE on or1k (PR104153) and broke SPARC bootstrap (PR104198). cond_exec_get_condition () returns the jump condition directly and we now pass it to the backend. The or1k backend modified the condition in-place (other backends do that as well) but this modification is not reverted when the sequence in question is discarded. Therefore we copy the RTX instead of using it directly. The SPARC problem is due to the SPARC backend recreating the initial condition when being passed a CC comparison. This causes the sequence to read from an already overwritten condition operand. Generally, this could also happen on other targets. The workaround is to always first emit to a temporary. In a second run of noce_convert_multiple_sets_1 we know which sequences actually require the comparison and will use no temporaries if all sequences after the current one do not require it. PR rtl-optimization/104198 PR rtl-optimization/104153 gcc/ChangeLog: * ifcvt.cc (noce_convert_multiple_sets_1): Copy rtx instead of using it directly. Rework comparison handling and always perform a second pass. gcc/testsuite/ChangeLog: * gcc.dg/pr104198.c: New test.
[Bug rtl-optimization/104198] [12 regression] ifcvt change breaks 64-bit SPARC bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104198 --- Comment #16 from CVS Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:d0d4601ccde3c4849f6e7244035f1a899d608cb7 commit r12-7114-gd0d4601ccde3c4849f6e7244035f1a899d608cb7 Author: Robin Dapp Date: Tue Feb 8 16:11:20 2022 +0100 ifcvt: Fix PR104153 and PR104198. This is a bugfix for r12-6747-gaa8cfe785953a0 which caused an ICE on or1k (PR104153) and broke SPARC bootstrap (PR104198). cond_exec_get_condition () returns the jump condition directly and we now pass it to the backend. The or1k backend modified the condition in-place (other backends do that as well) but this modification is not reverted when the sequence in question is discarded. Therefore we copy the RTX instead of using it directly. The SPARC problem is due to the SPARC backend recreating the initial condition when being passed a CC comparison. This causes the sequence to read from an already overwritten condition operand. Generally, this could also happen on other targets. The workaround is to always first emit to a temporary. In a second run of noce_convert_multiple_sets_1 we know which sequences actually require the comparison and will use no temporaries if all sequences after the current one do not require it. PR rtl-optimization/104198 PR rtl-optimization/104153 gcc/ChangeLog: * ifcvt.cc (noce_convert_multiple_sets_1): Copy rtx instead of using it directly. Rework comparison handling and always perform a second pass. gcc/testsuite/ChangeLog: * gcc.dg/pr104198.c: New test.
[Bug target/104448] New: [10/11/12 Regression] ICE: in initialize, at function-abi.cc:108 with -mavx5124vnniw / -mavx5124fmaps -mno-xsave -mabi=ms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104448 Bug ID: 104448 Summary: [10/11/12 Regression] ICE: in initialize, at function-abi.cc:108 with -mavx5124vnniw / -mavx5124fmaps -mno-xsave -mabi=ms Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Compiler output: (empty source file) $ echo > testcase.c $ x86_64-pc-linux-gnu-gcc -mavx5124vnniw -mno-xsave -mabi=ms testcase.c testcase.c: internal compiler error: in initialize, at function-abi.cc:108 0x6dff4d predefined_function_abi::initialize(unsigned int, HARD_REG_SET const&) /repo/gcc-trunk/gcc/function-abi.cc:108 0xcf5695 backend_init /repo/gcc-trunk/gcc/toplev.cc:1785 0xcf5695 do_compile /repo/gcc-trunk/gcc/toplev.cc:2140 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -mavx5124fmaps -mno-xsave -mabi=ms testcase.c testcase.c: internal compiler error: in initialize, at function-abi.cc:108 0x6dff4d predefined_function_abi::initialize(unsigned int, HARD_REG_SET const&) /repo/gcc-trunk/gcc/function-abi.cc:108 0xcf5695 backend_init /repo/gcc-trunk/gcc/toplev.cc:1785 0xcf5695 do_compile /repo/gcc-trunk/gcc/toplev.cc:2140 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7089-20220208123931-g0103c2e4082-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-7089-20220208123931-g0103c2e4082-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220208 (experimental) (GCC)
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #7 from Andreas Schwab --- If you make all-target-libgo all dependencies are respected.
[Bug c/104447] New: [9/10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104447 Bug ID: 104447 Summary: [9/10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With versions r8+ and file ./gcc.target/i386/pr55512-4.c : $ gcc-12-20220206 -c pr55512-4.c -O2 -pg -fchecking during RTL pass: reload pr55512-4.c: In function 'bar': pr55512-4.c:14:1: internal compiler error: maximum number of LRA assignment passes is achieved (30) 14 | } | ^ 0xa93650 lra_assign(bool&) ../../gcc/lra-assigns.cc:1694 0xa8e73c lra(_IO_FILE*) ../../gcc/lra.cc:2395 0xa473f9 do_reload ../../gcc/ira.cc:5940 0xa473f9 execute ../../gcc/ira.cc:6126
[Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104446
Bug ID: 104446
Summary: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at
explow.cc:59
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
With file ./gcc.target/i386/pr65588.c :
$ gcc-12-20220206 -c pr65588.c -O2 -m32 -mrtd -finstrument-functions
during RTL pass: combine
pr65588.c: In function 't':
pr65588.c:10:19: internal compiler error: in trunc_int_for_mode, at
explow.cc:59
10 | int t () { a = 0; }
| ^
0x8b5d13 trunc_int_for_mode(long, machine_mode)
../../gcc/explow.cc:59
0x8b5d28 trunc_int_for_mode(poly_int<1u, long>, machine_mode)
../../gcc/explow.cc:86
0x8aa928 gen_int_mode(poly_int<1u, long>, machine_mode)
../../gcc/emit-rtl.cc:542
0xbc3d78 for_each_inc_dec_find_inc_dec
../../gcc/rtlanal.cc:3711
0xbc3d78 for_each_inc_dec(rtx_def*, int (*)(rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, void*), void*)
../../gcc/rtlanal.cc:3750
0x17597af try_combine
../../gcc/combine.cc:3346
0x175f3cc combine_instructions
../../gcc/combine.cc:1269
0x175f3cc rest_of_handle_combine
../../gcc/combine.cc:14922
0x175f3cc execute
../../gcc/combine.cc:14967
[Bug c/104445] New: [12 Regression] ICE in vect_create_partial_epilog, at tree-vect-loop.cc:5098
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104445
Bug ID: 104445
Summary: [12 Regression] ICE in vect_create_partial_epilog, at
tree-vect-loop.cc:5098
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20210711 and 20210718, at -O3 or -Ofast :
$ cat z1.c
signed char a;
signed char f (int i, int j)
{
signed char c;
while (i != 0)
{
a ^= j;
++c;
++i;
}
return c;
}
$ gcc-12-20220206 -c z1.c -m32 -O3 -mavx -mno-mmx
during GIMPLE pass: vect
z1.c: In function 'f':
z1.c:2:13: internal compiler error: in vect_create_partial_epilog, at
tree-vect-loop.cc:5098
2 | signed char f (int i, int j)
| ^
0xe32e69 vect_create_partial_epilog
../../gcc/tree-vect-loop.cc:5095
0xe3bd5f vect_transform_cycle_phi(_loop_vec_info*, _stmt_vec_info*, gimple**,
_slp_tree*, _slp_instance*)
../../gcc/tree-vect-loop.cc:7795
0x190fcad vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
../../gcc/tree-vect-stmts.cc:11276
0xe4b65f vect_transform_loop(_loop_vec_info*, gimple*)
../../gcc/tree-vect-loop.cc:9799
0xe7d565 vect_transform_loops
../../gcc/tree-vectorizer.cc:1004
0xe7d713 vect_transform_loops
../../gcc/tree-vectorizer.cc:1022
0xe7db86 try_vectorize_loop_1
../../gcc/tree-vectorizer.cc:1133
0xe7db86 try_vectorize_loop
../../gcc/tree-vectorizer.cc:1164
0xe7e0c4 execute
../../gcc/tree-vectorizer.cc:1278
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #6 from Svante Signell --- OK, forget about the gotools. The problem is that libgo is built _before_ libatomic and libbacktrace. A Debian error??
[Bug tree-optimization/104444] New: Missing constant folding in shift expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Bug ID: 10
Summary: Missing constant folding in shift expression.
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cassio.neri at gmail dot com
Target Milestone: ---
#include
inline bool f(uint32_t m, int n) {
return (m >> n) != 0;
}
bool g(int n) {
return f(1 << 24, n);
}
g can be optimised to "return n <= 24". LLVM does that but gcc doesn't.
The example above drove me to another missing optimisation opportunity based on
undefined behaviour. (Perhaps a matter for other report?)
bool h(uint32_t m, int n) {
return (n >= 0 && n < 32) || (m >> n) != 0;
}
If (n >= 0 && n < 32) is false, then (m >> n) is UB (in C++, probably also in
C). Therefore, h can be optimised to "return true" but gcc doesn't do that
(neither does LLVM).
See here: https://godbolt.org/z/hx9vGe6Kj
If confirmed, these bugs could be added to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Potentially related:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94789#c1
[Bug target/104422] nvptx: for-3.exe fail with driver 390.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104422 --- Comment #5 from Tom de Vries --- Still on GT1030, does not reproduce with 470.x, neither the minimal nor the complete for-3.c.
[Bug c++/104379] [9/10/11 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |-Wshadow warning given |-Wshadow warning given |three times |three times --- Comment #9 from Jakub Jelinek --- Fixed on the trunk so far. Note, GCC 11 and older doesn't have the warning-control.c* infrastructure, so all we could do there is TREE_NO_WARNING.
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:71e6353e1b03021bc8bbcf4bd67a5f14d09b5fb1 commit r12-7113-g71e6353e1b03021bc8bbcf4bd67a5f14d09b5fb1 Author: Jakub Jelinek Date: Tue Feb 8 20:17:55 2022 +0100 c++: Don't emit repeated -Wshadow warnings for templates/ctors [PR104379] The following patch suppresses extraneous -Wshadow warnings. On the testcase without the patch we emit 14 -Wshadow warnings, with the patch just 4. It is enough to warn once e.g. during parsing of the template or the abstract ctor, while previously we'd warn also on the clones of the ctors and on instantiation. In GCC 8 and earlier we didn't warn because check_local_shadow did /* Inline decls shadow nothing. */ if (DECL_FROM_INLINE (decl)) return; 2022-02-08 Jakub Jelinek PR c++/104379 * name-lookup.cc (check_local_shadow): When diagnosing shadowing of a member or global declaration, add warning suppression for the decl and don't warn again on it. * g++.dg/warn/Wshadow-18.C: New test.
[Bug c++/104403] [12 Regression] ICE while optimizing lambda that returns address of a static variable hidden in a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104403 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug target/102140] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2670 (insn does not satisfy its constraints) with -Og -fipa-cp -fno-tree-ccp -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102140 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug c++/104403] [12 Regression] ICE while optimizing lambda that returns address of a static variable hidden in a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104403 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1755141a9ea0dddabb52776cddc4c9325eed27c6 commit r12-7112-g1755141a9ea0dddabb52776cddc4c9325eed27c6 Author: Jakub Jelinek Date: Tue Feb 8 20:15:42 2022 +0100 c++: Remove superflous assert [PR104403] I've added the assert because start_decl diagnoses such vars for C++20 and earlier: if (current_function_decl && VAR_P (decl) && DECL_DECLARED_CONSTEXPR_P (current_function_decl) && cxx_dialect < cxx23) but as can be seen, we cam trigger the assert in older standards e.g. during non-manifestly constant evaluation. Rather than refining the assert that DECL_EXPRs for such vars don't appear for C++20 and older if they are inside of functions declared constexpr this patch just removes the assert, the code rejects encountering those vars in constant expressions anyway. 2022-02-08 Jakub Jelinek PR c++/104403 * constexpr.cc (cxx_eval_constant_expression): Don't assert DECL_EXPRs of TREE_STATIC vars may only appear in -std=c++23. * g++.dg/cpp0x/lambda/lambda-104403.C: New test.
[Bug target/102140] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2670 (insn does not satisfy its constraints) with -Og -fipa-cp -fno-tree-ccp -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102140 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0c3e491a4e5ae74bfbed6d167d403d262b5a4adc commit r12-7111-g0c3e491a4e5ae74bfbed6d167d403d262b5a4adc Author: Jakub Jelinek Date: Tue Feb 8 20:14:30 2022 +0100 rs6000: Fix up vspltis_shifted [PR102140] The following testcase ICEs, because (const_vector:V4SI [ (const_int 0 [0]) repeated x3 (const_int -2147483648 [0x8000]) ]) is recognized as valid easy_vector_constant in between split1 pass and end of RA. The problem is that such constants need to be split, and the only splitter for that is: (define_split [(set (match_operand:VM 0 "altivec_register_operand") (match_operand:VM 1 "easy_vector_constant_vsldoi"))] "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode) && can_create_pseudo_p ()" There is only a single splitting pass before RA, so after that finishes, if something gets matched in between that and end of RA (after that can_create_pseudo_p () would be no longer true), it will never be successfully split and we ICE at final.cc time or earlier. The i386 backend (and a few others) already use (cfun->curr_properties & PROP_rtl_split_insns) as a test for split1 pass finished, so that some insns that should be split during split1 and shouldn't be matched afterwards are properly guarded. So, the following patch does that for vspltis_shifted too. 2022-02-08 Jakub Jelinek PR target/102140 * config/rs6000/rs6000.cc (vspltis_shifted): Return false also if split1 pass has finished already. * gcc.dg/pr102140.c: New test.
[Bug middle-end/104285] openmp offload linker issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104285 --- Comment #1 from Ye Luo --- Here is a minimal reproducer. https://github.com/ye-luo/openmp-target/tree/master/tests/linking/two_identical_templates $ g++ -fopenmp -foffload=nvptx-none -O3 -c test_a.cpp $ g++ -fopenmp -foffload=nvptx-none -c test_a.cpp $ g++ -fopenmp -foffload=nvptx-none -c test_b.cpp $ g++ -fopenmp -foffload=nvptx-none main.cpp test_a.o test_b.o lto1: fatal error: test_a.o: section _Z8test_mapIfEvv$_omp_fn$0.2375 is missing compilation terminated. mkoffload: fatal error: x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1 exit status compilation terminated. lto-wrapper: fatal error: /soft/gcc/gcc-12-dev-2022-02-08/libexec/gcc/x86_64-pc-linux-gnu/12.0.1//accel/nvptx-none/mkoffload returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status $ g++ -fopenmp -foffload=disable -c test_a.cpp $ g++ -fopenmp -foffload=disable -c test_b.cpp g++ -fopenmp -foffload=disable main.cpp test_a.o test_b.o Using be862bf1f612c884597ace4cbfdec972a0bf0eef from master
[Bug c++/104418] [C++17+] Error inheriting base class constructors by using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104418 --- Comment #7 from Fedor Chelnokov --- Thanks. I submitted Clang bug: https://github.com/llvm/llvm-project/issues/53653
[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354 Jakub Jelinek changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org, ||rearnsha at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- It could be e.g. done by having the targetm.const_not_ok_for_debug_p target hook not return true for the UNSPEC_TLS case and have some new target hook that would handle emitting debug info for an UNSPEC. Or a way to just quiet the note (I'll repeat it is -fchecking only) would be to use as the operand of UNSPEC_TLS not const0_rtx as it does, but some magic SYMBOL_REF with SYMBOL_REF_TLS_MODEL non-zero on it. Say like: --- gcc/config/aarch64/aarch64.md.jj2022-01-11 23:11:21.682300103 +0100 +++ gcc/config/aarch64/aarch64.md 2022-02-08 19:51:00.581676457 +0100 @@ -6833,7 +6833,8 @@ (define_insn "ldr_got_tiny_sidi" (define_insn "aarch64_load_tp_hard" [(set (match_operand:DI 0 "register_operand" "=r") - (unspec:DI [(const_int 0)] UNSPEC_TLS))] + (unspec:DI [(match_operand 1 "aarch64_tls_le_symref" "S")] + UNSPEC_TLS))] "" "mrs\\t%0, tpidr_el0" [(set_attr "type" "mrs")] --- gcc/config/aarch64/aarch64.cc.jj2022-02-04 14:36:54.262615676 +0100 +++ gcc/config/aarch64/aarch64.cc 2022-02-08 19:46:58.206051731 +0100 @@ -18474,7 +18474,9 @@ aarch64_load_tp (rtx target) target = gen_reg_rtx (Pmode); /* Can return in any reg. */ - emit_insn (gen_aarch64_load_tp_hard (target)); + rtx sym = gen_rtx_SYMBOL_REF (Pmode, ""); + SYMBOL_REF_FLAGS (sym) = TLS_MODEL_LOCAL_EXEC << SYMBOL_FLAG_TLS_SHIFT; + emit_insn (gen_aarch64_load_tp_hard (target, sym)); return target; }
[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568 --- Comment #10 from palmer at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #7) > (In reply to Jonathan Wakely from comment #6) > > (In reply to Jonathan Wakely from comment #5) > > > (In reply to palmer from comment #3) > > > > It looks like LLVM already has inline atomics, so presumably the same > > > > issues > > > > would arise when mixing libstdc++ libraries compiled with LLVM and GCC. > > > > > > Yup. > > > > But not just "when mixing libstdc++ libraries". When mixing pretty much any > > C++ code that uses libstdc++ headers. > > Oh actually, sorry, that's wrong. The atomic policy for libstdc++ is set at > configure time, based on the GCC building it. We define a macro, and that is > fixed for the lifetime of that libstdc++ installation. So it doesn't matter > if you compile those same headers with Clang, which _could_ use atomic > built-ins, the atomic policy is still decided by the macro which doesn't > change after installation. > > So it's only a problem when mixing user code compiled with old and new > libstdc++ headers. > > And I've been confusing the _GLIBCXX_ATOMIC_BUILTINS macro with the > _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY macro. I hadn't even noticed the _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY macro, thanks! > If _GLIBCXX_ATOMIC_BUILTINS changes from undefined to 1, I think that's OK. > Old code will still call the non-inline functions in libstdc++.so, but those > will now be consistent with the inline ones that new code is calling. My specific worry was users mixing in routines from two different versions of libstdc++: for example, maybe there's some statically linked executable that puts a shared pointer into a mmap'd region, which it then expects to work when After signing off last night I realized that none of that would work anyway, though, as even with the same library on both ends users would end up with a different mutex and thus races. So I think that one isn't worth worrying about. [snip, I'm mixing two replies here] > Thanks. Changing that will cause an ABI break in the headers (and so affect > user code, not just the libstdc++.so library). > > Clang and GCC will still be compatible, because the macros are still set > once by configure when building libstdc++. >From my reading of this, GCC and clang will build libstdc++ binaries with incompatible ABIs: clang has inline atomics, so the 2-byte CAS check will succeed and we'll end up with libstdcxx_atomic_lock_policy=atomic . I don't actually have a clang build around to test that with, though, and I'm not sure if folks are shipping clang-built libstdc++ anywhere (and if so, are expecting it to be compatible with a GCC-built libstdc++). > One solution would be to override the checks in libstdc++-v3/acinclude.m4 so > that _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY is also #undef for RISC-V, even after > the atomic built-ins are supported. That would preserve the ABI, but would > mean ref-counting in libstdc++ is sub-optimal. > > Or let the default change, and vendors who want to preserve the old ABI can > configure with --with-libstdcxx-lock-policy=mutex to override the default. I guess I'm not really sure here: normally I'd say we're stuck with the default being ABI compatible, but I don't know the rules in libstdc++. I'm assuming that forcing the default to be mutex could still allow users who want atomic to configure with --with-libstdcxx-lock-policy=atomic, so at least there's a path forward. IIUC users will get link errors when moving between the two flavors (the explicit template instantiations will have different integer values), so at least there's a way for distros to make sure they've re-built everything if they want to change. I could also imagine a much more complicated third option: essentially upgrading the mutex to an RW-like lock and allowing the atomic-based routines to proceed concurrently. I poked around the locking code a bit have no idea if this would even be possible, it's all complicated enough that it seems like at best a bad idea. I guess this is really a distro sort of question, but I'd lean towards forcing the default to mutex on RISC-V, thus keeping ABI compatibility. Then at least the distros can pick if they want to have a flag day around this.
[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354 --- Comment #6 from Jakub Jelinek --- In this particular case it is: (note 38 19 20 (var_location p (unspec:DI [ (const_int 0 [0]) ] UNSPEC_TLS)) NOTE_INSN_VAR_LOCATION) where p's value should be equal to that __builtin_thread_pointer () aka the base of the TLS region. I wonder if it could be represented as DW_OP_lit0 DW_OP_form_tls_address, one would need to test that in debugger. And if it works, figure out some target independent way or perhaps a target hook that would propagate this case from the target dependent UNSPEC_TLS to dwarf2out.cc that it could emit such location.
[Bug c++/104410] [11 Regression] Internal error using default-initialized constexpr bool in requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104410 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Patrick Palka --- Fixed for GCC 11.3/12.
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #5 from Ian Lance Taylor --- > The only issue to resolve is how to make sure libatomic and libbacktrace > builds in build/i686-gnu before libgo/gotools. That question doesn't sound right. The gotools are built for the target. They shouldn't depend on build/i686-gnu, which is built for the host. The gotools should depend on the target libatomic and the target libbacktrace, and they do. What problem are you trying to solve?
[Bug libstdc++/104443] common_iterator::operator-> is not correctly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104443 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-02-08
[Bug libstdc++/104443] New: common_iterator::operator-> is not correctly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104443 Bug ID: 104443 Summary: common_iterator::operator-> is not correctly implemented Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: de34 at live dot cn Target Milestone: --- When the adapted iterator type I is a pointer type or has operator->, std::common_iterator::operator-> is required to return the iterator by reference ([common.iter.access]/(5.1), and std::get for std::variant always returns reference). However, currently libstdc++'s implementation returns the iterator by value in these cases, because "return _M_it;" is used and the return type is specified by decltype(auto). "return (_M_it);" should be used instead. Currently only libc++ correctly implements both common_iterator::operator-> and iterator_traits>::pointer. See https://gcc.godbolt.org/z/1Tn5cGrhh.
[Bug c++/104410] [11 Regression] Internal error using default-initialized constexpr bool in requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104410 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:411db3b4cf8655ecb5b7d666318546c73f2d156b commit r11-9544-g411db3b4cf8655ecb5b7d666318546c73f2d156b Author: Patrick Palka Date: Tue Feb 8 09:11:29 2022 -0500 c++: satisfaction value of type const bool [PR104410] Here constant evaluation of the atomic constraint use_func_v sensibly yields an INTEGER_CST of type const bool, but the assert in satisfaction_value expects unqualified bool. So let's just relax the assert to accept cv-qualified bool. PR c++/104410 gcc/cp/ChangeLog: * constraint.cc (satisfaction_value): Relax assert to accept cv-qualified bool. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-pr104410.C: New test. (cherry picked from commit 7ff201d85fad11ba6365a5612124b75b385a97bd)
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #4 from Andreas Schwab ---
Makefile.def already has the required dependencies:
dependencies = { module=all-target-libgo; on=all-target-libbacktrace; };
dependencies = { module=all-target-libgo; on=all-target-libffi; };
dependencies = { module=all-target-libgo; on=all-target-libatomic; };
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #3 from Svante Signell --- With the proposed patches everything builds fine. The only issue to resolve is how to make sure libatomic and libbacktrace builds in build/i686-gnu before libgo/gotools. Any ideas? I'm not sure if this is a Debian or upstream problem. After a failed build I did: make -C build configure-target-libatomic make -C build/i686-gnu/libatomic/ make -C build configure-target-libbacktrace make -C build/i686-gnu/libbacktrace/ debian/rules build fakeroot debian/rules binary All debs built fine. Additionally make -C build/i686-gnu/libgo check reports in build/i686-gnu/libgo/libgo.sum === libgo Summary === # of expected passes181 # of unexpected failures9 Thanks!
[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103147 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jonathan.wright at arm dot com, ||wirkus at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Note, -fpack-struct is an ABI changing option, so it should be used with extra care. Anyway, I guess the backends (both aarch64 and arm) need to decide what exactly they want. Either for these internal lang_hooks.types.simulate_record_decl created types temporarily rest to default the -fpack-struct stuff, or allow them to have smaller alignment, or increase the alignment afterwards. Because those tree t = lang_hooks.types.simulate_record_decl (input_location, tuple_type_name, make_array_slice (&field, 1)); gcc_assert (TYPE_MODE_RAW (t) == TYPE_MODE (t) && TYPE_ALIGN (t) == alignment); and ls64_arm_data_t = lang_hooks.types.simulate_record_decl (input_location, tuple_type_name, make_array_slice (&field, 1)); gcc_assert (TYPE_MODE (ls64_arm_data_t) == V8DImode); gcc_assert (TYPE_MODE_RAW (ls64_arm_data_t) == TYPE_MODE (ls64_arm_data_t)); gcc_assert (TYPE_ALIGN (ls64_arm_data_t) == 64); assertions otherwise of course fail. Now, seems the arm backend actually doesn't assert this. Note, when those types were defined in arm_neon.h, -fpack-struct usedd to be applied to those. The changes were done in r12-4907-g8197ab94b47c814632d758dd36a121ad4114ff70 and r12-5955-gfdcddba8f29ea3878851b8b4cd37d0fd3476d3bf
[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |10.4
Last reconfirmed||2022-02-08
--- Comment #10 from Jonathan Wakely ---
I think we should backport it except for the removal of the default
constructors for {back_,front_,}insert_iterator, ostream_iterator and
basic_istream_view. If we keep those default constructible on the release
branches I think the chance of breaking any code is minimal.
[Bug libstdc++/104442] New: atomic::wait incorrectly loops in case of spurious notification when __waiter is shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104442
Bug ID: 104442
Summary: atomic::wait incorrectly loops in case of spurious
notification when __waiter is shared
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: poulhies at adacore dot com
Target Milestone: ---
Created attachment 52377
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52377&action=edit
patch fixing the issue
We are observing a deadlock in 100334.cc on vxworks.
This is caused by :
template
void
_M_do_wait_v(_Tp __old, _ValFn __vfn)
{
__platform_wait_t __val;
if (__base_type::_M_do_spin_v(__old, __vfn, __val))
return;
do
{
__base_type::_M_w._M_do_wait(__base_type::_M_addr, __val);
}
while (__detail::__atomic_compare(__old, __vfn()));
}
When several thread are sharing the waiter (as in 100334.cc), the notify_one()
will wake all threads blocked in the _M_do_wait() above. The thread whose data
changed exits the loop correctly, but the others are looping back in
_M_do_wait() with the same arguments. As the waiter's value has changed since
the previous iteration but not __val, the method directly returns (as if it had
detected a notification) and the loop continues.
On GNU/Linux, the test is PASS because the main thread is still scheduled and
will do a .store(1) on all atoms, unblocking all the busy-waiting thread (but
the thread doing a busywait can still be observed with gdb).
On vxworks, the main thread is never scheduled again (I think there's no
preemption at the same prio level) and the busy-wait starves the system.
The attached patch is a possible fix. It moves the spin() call inside the loop,
updating the __val at every iteration. A better fix is probably possible but
may require some refactoring (a bit more than I'm comfortable with).
I've checked the patch for regression on gcc-master for x86_64. It also fixes
the test on gcc-11 for aarch64-vxworks7.
[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904 --- Comment #9 from Jonathan Wakely --- (In reply to Hannes Hauswedell from comment #8) > Hi, I wanted to ask politely whether you have discussed this issue and came > to a conclusion? No, because the current priority is gcc 12.
[Bug target/104422] nvptx: for-3.exe fail with driver 390.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104422
--- Comment #4 from Tom de Vries ---
(In reply to Tom de Vries from comment #3)
> Reproduces both with and without GOMP_NVPTX_JIT=-O0.
Pff, that was an artefact of having bumped the default ptx isa to 6.3.
So, let's try again ...
Reproduced with 390.147 driver on pascal card, GT 1030, gcc build from master
commit "[nvptx] Unbreak build, add PTX_ISA_SM70". Doens't reproduce with
GOMP_NVPTX_JIT=-O0.
Minimal test-case:
...
#define N 1500
#pragma omp declare target
int a[N];
__attribute__((noinline, noclone)) void
f3_ds_normal ()
{
volatile int s3 = 1;
#pragma omp distribute simd
for (int i = 0; i < N; i += s3)
a[i] += 7;
}
#pragma omp end declare target
int
main ()
{
for (int i = 0; i < N; i++)
a[i] = i - 29;
#pragma omp target update to(a)
#pragma omp target teams
f3_ds_normal ();
#pragma omp target update from(a)
for (int i = 0; i < N; i++)
if (a[i] != i - 22)
__builtin_abort ();
return 0;
}
...
[Bug target/104441] [12 Regression] vzeroupper is placed at the wrong place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104441 --- Comment #2 from H.J. Lu --- Created attachment 52376 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52376&action=edit A patch I am testing this.
[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904 --- Comment #8 from Hannes Hauswedell --- Hi, I wanted to ask politely whether you have discussed this issue and came to a conclusion? It if it is still being discussed, can you at least "confirm" this issue and put it on some list for the next patch-level releases? Otherwise, it will be forgotten. And the longer we wait with a decision, the less likely it will be that it can be backported. Thank you!
[Bug target/104345] [12 Regression] "nvptx: Transition nvptx backend to STORE_FLAG_VALUE = 1" patch made some code generation worse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104345 --- Comment #9 from Thomas Schwinge --- OK! Putting your "nvptx: Add support for 64-bit mul.hi (and other) instructions" on top, that considerably changes (simplifies!) the generated '__muldc3' PTX code; the regression disappears. :-) (I have, so far, only manually tested 'libgomp.oacc-c-c++-common/reduction-cplx-dbl.c'. I'll report later in the unlikely case that any other/new issues should appear.) (And, will later test your "nvptx: Tweak constraints on copysign instructions" on top, too.)
