[Bug tree-optimization/109696] [14 Regression] ice: tree check fail since r14-377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109696 --- Comment #4 from Jakub Jelinek --- r14-458-g2b8a27634f5d28e3e7c4a08bf065f2daada7aed2 fixed it.
[Bug ipa/112372] GCC omits function location in DWARF at higher optimisation levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112372 Richard Biener changed: What|Removed |Added Component|debug |ipa CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #5 from Richard Biener --- Probably a duplicate of a recent similar bug also because of ICF.
[Bug middle-end/112382] `(a&b) != a` where a is known to have one known bit set is not optimized to ((~b&a)>>shift) & 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112382 Richard Biener changed: What|Removed |Added Target||x86_64-*-* --- Comment #1 from Richard Biener --- Note ((~b&a)>>shift) & 1 is two more GIMPLE ops than (a&b) != a so I'd expect the reverse transform on GIMPLE and maybe target specific expansion tweaks (or combine at work). Mangling the testcases to expect CSE with the (a&b) != a would be the thing to test on GIMPLE (maybe simply expect ICF to happen?!)
[Bug tree-optimization/112370] -Wfree-nonheap-object in std::vector dtor on sapphirerapids with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112370 --- Comment #2 from Alexander Grund --- FWIW: I tried to run cvise on this however it created an invalid example where indeed a non-heap pointer would be freed. I'll attach it anyway for reference as it took hours to run the reduce
[Bug tree-optimization/112370] -Wfree-nonheap-object in std::vector dtor on sapphirerapids with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112370 --- Comment #3 from Alexander Grund --- Created attachment 56513 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56513&action=edit INVALID reduced example (after running cvise on the former example)
[Bug target/112384] a non-constant vec dup should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112384
Richard Biener changed:
What|Removed |Added
Target|aarch64 |aarch64, x86_64-*-*
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-11-06
--- Comment #2 from Richard Biener ---
Confirmed. Note for f2 the target needs to support .VEC_EXTRACT with variable
index.
OTOH we miss to transform
i_4 = VIEW_CONVERT_EXPR(t)[i_2];
tt_5 = {i_4, i_4, i_4, i_4};
into
tt_3 = {i_2, i_2, i_2, i_2};
r_6 = VEC_PERM_EXPR ;
but the complication is that 't' isn't in SSA form (which is also why
it goes through memory here).
On x86_64 with SSE4.1 we get
f1:
.LFB0:
.cfi_startproc
andl$3, %edi
movd%edi, %xmm2
pshufd $0, %xmm2, %xmm1
pslld $2, %xmm1
pshufb .LC1(%rip), %xmm1
paddb .LC2(%rip), %xmm1
pshufb %xmm1, %xmm0
ret
f2:
.LFB1:
.cfi_startproc
andl$3, %edi
movaps %xmm0, -24(%rsp)
movd-24(%rsp,%rdi,4), %xmm1
pshufd $0, %xmm1, %xmm0
ret
I suspect the memory case is actually faster. With AVX512VL this
improves to
f1:
.LFB0:
.cfi_startproc
andl$3, %edi
vmovdqa %xmm0, %xmm1
vpbroadcastd%edi, %xmm0
vpermi2d%xmm1, %xmm1, %xmm0
ret
f2:
.LFB1:
.cfi_startproc
andl$3, %edi
vmovdqa %xmm0, -24(%rsp)
vpbroadcastd-24(%rsp,%rdi,4), %xmm0
ret
AVX2 has the odd
f1:
.LFB0:
.cfi_startproc
andl$3, %edi
vinserti128 $1, %xmm0, %ymm0, %ymm0
vmovd %edi, %xmm2
vpbroadcastd%xmm2, %xmm1
vinserti128 $1, %xmm1, %ymm1, %ymm1
vpermd %ymm0, %ymm1, %ymm0
vzeroupper
ret
where sth feels wrong - f2 is similar to AVX512. It's not clear whether
the f1 IL is better in the end.
[Bug target/112387] RISC-V: failed to SLP INT64 gather load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112387 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-11-06 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Indeed less gathers should be better. Note gathers are costed as vector_load (for the index vector) and N times scalar_load when not emulated. There isn't a specific gather_load. I suspect your scalar_load costs do not inter-operate with vector_* costs (aka you add apples and oranges?)
[Bug tree-optimization/112402] [11/12/13/14 Regression] Path splitting causes if-conversion miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112402 --- Comment #1 from Richard Biener --- So the question is whether we should do more if-conversion on GIMPLE then (or axe path splitting or move it to RTL)
[Bug tree-optimization/112369] [14 regression] ICE when building webkit-gtk with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112369 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:d803438e0c4016aff720fad418377c5b13567063 commit r14-5145-gd803438e0c4016aff720fad418377c5b13567063 Author: Richard Biener Date: Mon Nov 6 08:58:18 2023 +0100 tree-optimization/112369 - strip_float_extensions and vectors The following fixes an error in strip_float_extensions when facing vector conversions. PR tree-optimization/112369 * tree.cc (strip_float_extensions): Use element_precision. * gcc.dg/pr112369.c: New testcase.
[Bug middle-end/112367] wrong rounding of sum of floating-point constants with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112367 --- Comment #7 from Paul Zimmermann --- thank you all and sorry for the noise
[Bug tree-optimization/112369] [14 regression] ICE when building webkit-gtk with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112369 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Richard Biener --- Fixed.
[Bug libstdc++/112397] Two persistent libstdc++ test failures on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397 Jonathan Wakely changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- The .cold symbol is created by gcc, I don't see any way to control its visibility in the source. So maybe a target bug in the compiler, not a library bug.
[Bug tree-optimization/112361] [14 Regression] avx512f-reduce-op-1.c miscompiled since r14-5076
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112361 --- Comment #6 from Robin Dapp --- So "before" we created vect__3.12_55 = MEM [(float *)vectp_a.10_53]; vect__ifc__43.13_57 = VEC_COND_EXPR ; // _ifc__43 = _24 ? _3 : 0.0; stmp__44.14_58 = BIT_FIELD_REF ; stmp__44.14_59 = r3_29 + stmp__44.14_58; ... in vect_expand_fold_left. Now, as intended, there is no VEC_COND anymore and we just create the bit-field reduction over the unmasked vector. We could refrain from creating the COND_OP in the first place as Jakub mentioned (I guess we know already in if-conv that we shouldn't), re-insert a VEC_COND or create a COND_OP chain (instead of an OP chain) in vect_expand_fold_left by passing it the mask (and is_cond_op). Having several COND_OPs here might make analysis of subsequent passes more difficult?
[Bug tree-optimization/111950] [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950 Richard Biener changed: What|Removed |Added Attachment #56502|0 |1 is obsolete|| --- Comment #10 from Richard Biener --- Created attachment 56514 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56514&action=edit patch Ah, simple error on my side.
[Bug libstdc++/112351] libstdc++ locale init doesn't handle __gthread_once failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112351 --- Comment #1 from Richard Biener --- The question is also how much of explicit thread safety is needed when the init is now happening inside libstdc++ (thus from _init which should be already ensured to execute exactly once)? Is that (_init time) done for all targets/configurations btw?
[Bug tree-optimization/112361] [14 Regression] avx512f-reduce-op-1.c miscompiled since r14-5076
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112361 --- Comment #7 from rguenther at suse dot de --- On Mon, 6 Nov 2023, rdapp at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112361 > > --- Comment #6 from Robin Dapp --- > So "before" we created > > vect__3.12_55 = MEM [(float *)vectp_a.10_53]; > vect__ifc__43.13_57 = 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 }>; > // _ifc__43 = _24 ? _3 : 0.0; > stmp__44.14_58 = BIT_FIELD_REF ; > stmp__44.14_59 = r3_29 + stmp__44.14_58; > ... > > in vect_expand_fold_left. Note that this wasn't correct in all cases (wrt signed zeros and sign-dependent rounding). > Now, as intended, there is no VEC_COND anymore and we just create the > bit-field > reduction over the unmasked vector. That's invalid for a COND_OP. We either have to emulate that COND_OP by materializing a VEC_COND_EXPR as before when that's semantically valid, or refrain from vectorizing (I don't think we want to emit N compare & jump to scalarize the mask effect). > We could refrain from creating the COND_OP in the first place as Jakub > mentioned (I guess we know already in if-conv that we shouldn't), re-insert a > VEC_COND or create a COND_OP chain (instead of an OP chain) in > vect_expand_fold_left by passing it the mask (and is_cond_op). > Having several COND_OPs here might make analysis of subsequent passes more > difficult? pass in the mask and is_cond_op and create the VEC_COND_EXPR in vect_expand_fold_left. But make sure to disallow vectorizing the invalid cases.
[Bug c++/112377] Implement -Walloc-size in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112377 --- Comment #3 from Jonathan Wakely --- (In reply to David Binderman from comment #0) > I think that should be enough to implement the new warning for C++. Certainly not. Apart from the fact that there's a lot more needed than just making the option accepted by the C++ front end, there's the question of what it should actually do. Would it only warn for malloc, calloc etc., or operator new as well? And what about warning about alignment for overaligned types, both when using operator new (with or without a std::align_val_t argument) and malloc. Should that be a separate warning?
[Bug target/111720] RISC-V: Ugly codegen in RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720 --- Comment #28 from Richard Biener --- I tried to look up the requirements of __riscv_vle8_v_u8m2 in the vector intrinsic specs but besides listing all those intrinsics the spec doesn't contain _any_ documentation? The 2nd arg is named 'vl' which I interpret as vector length so that's so difficult for this intrinsic? Why isn't it just even a plain load? I read the specified 'vl' isn't exact but the intrinsics are still strongly typed, so a VLA typed gimple load should match here? And there should be a way to constrain the implementation somehow since 'arr' has limited size. Is the implementation constrained to use a vector length <= the specified 'vl'?
[Bug target/112393] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1208 with -mavx5124fmaps -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112393 --- Comment #4 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:f463ef79ddb403570461343ebda0c1aeac85d5bb commit r14-5147-gf463ef79ddb403570461343ebda0c1aeac85d5bb Author: liuhongt Date: Mon Nov 6 10:58:15 2023 +0800 Avoid generating RTL code when d->testing_p. gcc/ChangeLog: PR target/112393 * config/i386/i386-expand.cc (ix86_expand_vec_perm_vpermt2): Avoid generating RTL code when d->testing_p. gcc/testsuite/ChangeLog: * gcc.target/i386/pr112393.c: New test.
[Bug target/112393] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1208 with -mavx5124fmaps -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112393 --- Comment #5 from Hongtao.liu --- Fixed.
[Bug libfortran/112364] calloc used incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364 --- Comment #12 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:17df6ddcf11aef6d200305d35641a7deb2f430e1 commit r14-5148-g17df6ddcf11aef6d200305d35641a7deb2f430e1 Author: Tobias Burnus Date: Mon Nov 6 11:34:31 2023 +0100 libgfortran: Fix calloc call by swapping arg order [PR112364] The prototype of calloc is void *calloc(size_t nmemb, size_t size); denoting "an array of nmemb objects, each of whose size is size." (C23) In order to follow the meaning of the argument names and to silence a -Walloc-size warning, this commit swaps the order of the two args to read now: calloc (1, sizeof (transfer_queue)); libgfortran/ChangeLog: PR libfortran/112364 * io/async.c (enqueue_transfer, enqueue_done_id, enqueue_done, enqueue_close): Swap 1st and 2nd arg in calloc call.
[Bug target/111720] RISC-V: Ugly codegen in RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720 --- Comment #29 from JuzheZhong --- (In reply to Richard Biener from comment #28) > I tried to look up the requirements of __riscv_vle8_v_u8m2 in the vector > intrinsic specs but besides listing all those intrinsics the spec doesn't > contain _any_ documentation? The 2nd arg is named 'vl' which I interpret > as vector length so that's so difficult for this intrinsic? Why isn't it > just even a plain load? I read the specified 'vl' isn't exact but the > intrinsics are still strongly typed, so a VLA typed gimple load should match > here? And there should be a way to constrain the implementation somehow > since 'arr' has limited size. Is the implementation constrained to use a > vector length <= the specified 'vl'? Yes. 'vl' is vector length. The thing is that multiple types of intrinsics: __riscv_vle8_v_u8m2 __riscv_vle8_v_u8m2_tu __riscv_vle8_v_u8m2_tumu __riscv_vle8_v_u8m2_mu all of them will update elements index < vl. But for index >= vl elements, we have __riscv_vle8_v_u8m2 which don't care those value, so they can be any value. Wheras __riscv_vle8_v_u8m2_tu need index >= vl to be original old value.
[Bug tree-optimization/112404] New: [14 Regression] 521.wrf_r fails to build with internal compiler error: in get_vectype_for_scalar_type, at tree-vect-stmts.cc:13311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112404 Bug ID: 112404 Summary: [14 Regression] 521.wrf_r fails to build with internal compiler error: in get_vectype_for_scalar_type, at tree-vect-stmts.cc:13311 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- On x86_64-linux with -Ofast -march=znver4: /space/rguenther/install/trunk-r14-5145-vecupdate/usr/local/bin/gfortran -c -o module_fdda_psufddagd.fppized.o -I. -I./netcdf/include -I./inc -Ofast -march=znver4 -std=legacy -fconvert=big-endian -fno-openmp -g0 module_fdda_psufddagd.fppized.f90 during GIMPLE pass: slp module_fdda_psufddagd.fppized.f90:553:21: 553 |SUBROUTINE sfddagd(itimestep,dx,dt,xtime, & | ^ internal compiler error: in get_vectype_for_scalar_type, at tree-vect-stmts.cc:13311 0x2037204 get_vectype_for_scalar_type(vec_info*, tree_node*, unsigned int) /space/rguenther/src/gcc11queue/gcc/tree-vect-stmts.cc:13311 0x2045fb8 get_mask_type_for_scalar_type(vec_info*, tree_node*, unsigned int) /space/rguenther/src/gcc11queue/gcc/tree-vect-stmts.cc:13381 0x2046222 vect_check_scalar_mask /space/rguenther/src/gcc11queue/gcc/tree-vect-stmts.cc:2459 0x2046802 vectorizable_load /space/rguenther/src/gcc11queue/gcc/tree-vect-stmts.cc:9853 0x205b112 vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*, _slp_instance*, vec*) /space/rguenther/src/gcc11queue/gcc/tree-vect-stmts.cc:12954 0x1298b85 vect_slp_analyze_node_operations_1 /space/rguenther/src/gcc11queue/gcc/tree-vect-slp.cc:6141 going to reduce.
[Bug libstdc++/112351] libstdc++ locale init doesn't handle __gthread_once failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112351 --- Comment #2 from Jonathan Wakely --- Ah yes, that's a good point. Patrick's improvement affects this initialization. It's not done for all targets though, as not all targets have linker support for the init_priority attribute (notably, darwin doesn't).
[Bug libfortran/112364] calloc used incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||burnus at gcc dot gnu.org --- Comment #13 from Tobias Burnus --- FIXED by committing the obvious fix as obvious (comment 12). (Same as the obvious change as proposed by Steven in comment 8.) As the warning is new (since r14-5059-gd880e093d92084) and there is no real compelling reason to change it, I don't think it makes sense to queue it for backporting. Thanks for the report - and to all involved for the insight into the fine print of the C standards.
[Bug target/112405] New: GCN: "gcc.dg/vect/vect-simd-clone-20.c:22:1: error: conversion of register to a different size in 'view_convert_expr'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112405 Bug ID: 112405 Summary: GCN: "gcc.dg/vect/vect-simd-clone-20.c:22:1: error: conversion of register to a different size in 'view_convert_expr'" Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, testsuite-fail Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: ams at gcc dot gnu.org, avieira at gcc dot gnu.org, jules at gcc dot gnu.org Target Milestone: --- Target: GCN The test case 'gcc.dg/vect/vect-simd-clone-20.c' added in recent commit r14-5113-gaed00696a01ac065e9ed327434ec29d1cf50179e "vect: allow using inbranch simdclones for masked loops" ICEs for GCN target (tested '-march=gfx90a'): [...]/source-gcc/gcc/testsuite/gcc.dg/vect/vect-simd-clone-20.c: In function 'masked': [...]/source-gcc/gcc/testsuite/gcc.dg/vect/vect-simd-clone-20.c:22:1: error: conversion of register to a different size in 'view_convert_expr' VIEW_CONVERT_EXPR(loop_mask_1); _23 = VIEW_CONVERT_EXPR(loop_mask_1); during GIMPLE pass: vect dump file: ./vect-simd-clone-20.c.176t.vect [...]/source-gcc/gcc/testsuite/gcc.dg/vect/vect-simd-clone-20.c:22:1: internal compiler error: verify_gimple failed 0x1022708 verify_gimple_in_cfg(function*, bool, bool) [...]/source-gcc/gcc/tree-cfg.cc:5646 0xe6edd7 execute_function_todo [...]/source-gcc/gcc/passes.cc:2088 0xe6f6e5 execute_todo [...]/source-gcc/gcc/passes.cc:2142
[Bug tree-optimization/112404] [14 Regression] 521.wrf_r fails to build with internal compiler error: in get_vectype_for_scalar_type, at tree-vect-stmts.cc:13311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112404 Tamar Christina changed: What|Removed |Added Last reconfirmed||2023-11-6 CC||tnfchris at gcc dot gnu.org --- Comment #1 from Tamar Christina --- Same failure on AArch64 with SVE.
[Bug tree-optimization/112404] [14 Regression] 521.wrf_r fails to build with internal compiler error: in get_vectype_for_scalar_type, at tree-vect-stmts.cc:13311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112404 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |14.0 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine. SUBROUTINE sfddagd( regime, znt ,ite ,jte ) REAL, DIMENSION( ime, IN) :: regime, znt REAL, DIMENSION( ite, jte) :: wndcor_u LOGICAL wrf_dm_on_monitor IF( int4 == 1 ) THEN DO j=jts,jtf DO i=itsu,itf reg = regime(i-1, j) IF( reg > 10.0 ) THEN znt0 = znt(i-1, j) +znt(i, j) IF( znt0 <= 0.2) THEN wndcor_u(i,j) = 0.2 ENDIF ENDIF ENDDO ENDDO IF ( wrf_dm_on_monitor()) THEN ENDIF ENDIF END
[Bug middle-end/112406] New: [14 Regression] Several SPECCPU 2017 benchmarks fail with internal compiler error: in expand_insn, at optabs.cc:8305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 Bug ID: 112406 Summary: [14 Regression] Several SPECCPU 2017 benchmarks fail with internal compiler error: in expand_insn, at optabs.cc:8305 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tnfchris at gcc dot gnu.org Target Milestone: --- Target: aarch64* blender, wrf, imagick and fotonik in SPECCPU 2017 all fail with: blender/source/blender/blenkernel/intern/curve.c:1403:8: internal compiler error: in expand_insn, at optabs.cc:8305 1403 | float *BKE_curve_surf_make_orco(Object *ob) |^ 0x76681f expand_insn(insn_code, unsigned int, expand_operand*) /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/optabs.cc:8305 0xb43ac3 expand_insn(insn_code, unsigned int, expand_operand*) /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/optabs.cc:8274 0x9f0fd7 expand_fn_using_insn /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/internal-fn.cc:260 0x80026b expand_call_stmt /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:2737 0x80026b expand_gimple_stmt_1 /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:3880 0x80026b expand_gimple_stmt /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:4044 0x804917 expand_gimple_basic_block /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:6100 0x8065c7 execute /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:6835 Will reduce and bisect...
[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760 --- Comment #8 from CVS Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:0c42741ad95af3a1e3ac07350da4c3a94865ed63 commit r14-5151-g0c42741ad95af3a1e3ac07350da4c3a94865ed63 Author: Robin Dapp Date: Wed Oct 25 22:19:43 2023 +0200 internal-fn: Add VCOND_MASK_LEN. In order to prevent simplification of a COND_OP with degenerate mask (CONSTM1_RTX) into just an OP in the presence of length masking this patch introduces a length-masked analog to VEC_COND_EXPR: IFN_VCOND_MASK_LEN. It also adds new match patterns that allow the combination of unconditional unary, binary and ternay operations with the VCOND_MASK_LEN into a conditional operation if the target supports it. gcc/ChangeLog: PR tree-optimization/111760 * config/riscv/autovec.md (vcond_mask_len_): Add expander. * config/riscv/riscv-protos.h (enum insn_type): Add. * config/riscv/riscv-v.cc (needs_fp_rounding): Add !pred_mov. * doc/md.texi: Add vcond_mask_len. * gimple-match-exports.cc (maybe_resimplify_conditional_op): Create VCOND_MASK_LEN when length masking. * gimple-match.h (gimple_match_op::gimple_match_op): Always initialize len and bias. * internal-fn.cc (vec_cond_mask_len_direct): Add. (direct_vec_cond_mask_len_optab_supported_p): Add. (internal_fn_len_index): Add VCOND_MASK_LEN. (internal_fn_mask_index): Ditto. * internal-fn.def (VCOND_MASK_LEN): New internal function. * match.pd: Combine unconditional unary, binary and ternary operations into the respective COND_LEN operations. * optabs.def (OPTAB_D): Add vcond_mask_len optab. gcc/testsuite/ChangeLog: * gcc.dg/vect/vect-cond-arith-2.c: No vect cost model for riscv_v.
[Bug c++/112350] gcc is not triggering a dangling reference indicating stack use after return with -fsanitize=address and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112350 --- Comment #2 from Mohamed --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112350&GoAheadAndLogIn=1 it's shown here that the warning is triggered by setting -O3 optimization level to 3. I don't know if such behavior is expected i.e. triggering warning is coupled with optimization level!!! So the above link to compiler explorer example shows only the diagnostic error from the sanitizer, if -O3 is added the warning is triggered.
[Bug tree-optimization/112404] [14 Regression] 521.wrf_r fails to build with internal compiler error: in get_vectype_for_scalar_type, at tree-vect-stmts.cc:13311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112404 --- Comment #3 from Richard Biener --- Two issues, a simple omission where the ICE occurs and then failure to compute alignment info for SLP of .MASK_LOAD because SLP_INSTANCE_LOADS doesn't contain them. Oops.
[Bug middle-end/112359] [14 Regression] ICE: in expand_fn_using_insn, at internal-fn.cc:215 with -O -ftree-loop-if-convert -mavx512fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112359 --- Comment #2 from Robin Dapp --- Would something like + bool allow_cond_op = flag_tree_loop_vectorize +&& !gimple_bb (phi)->loop_father->dont_vectorize; in convert_scalar_cond_reduction be sufficient or are the more conditions to check still? Testing with the above and the reduced testcase worked FWIW.
[Bug libstdc++/110807] [13 Regression] Copy list initialisation of a vector raises a warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110807 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #11 from Alexandre Oliva --- > The new test fails with -m32 I've looked a bit into why. The memmove is optimized out by vrp (or, if that's disabled, by dom) on lp64, because it's guarded by two conditions: _10 > sizeof(long), and !(_14 > 1), where _10 is a signed long (ptrdiff_t) computed as the difference between the _M_p of _M_finish and _M_start in the preexisting vector, and _14 = (unsigned long)(_10*8 + _8), where _8 is the vector's finish offset. in order for the _14 condition to hold, _14 must be 0ul..1ul. Since _10 is long, _8 promotes to long in lp64, the addition is performed as a signed long, and then converted to unsigned long. _8 is loaded from memory as an unsigned int, and nothing is known about it, so its promoted operand is 0l..0xl. In order for _14 to be <= 1ul, _10 * 8 must be in the range -0xl..1l, and therefore _10 must be <= 0x1fffl..0l, which enables folding of the _10 condition as the entire range is <= sizeof(long). In the lp32 case, _10 is int, so _10*8 promotes to unsigned int for the addition, whose result is then NOPped to unsigned long. _8 is also loaded from memory as unsigned int, but because unsigned addition wraps around and _8 covers the full range, nothing can be inferred about the range of _10*8, and thus _10's range is only limited by overflow-avoidance in the signed multiplication: -0x1fffl..0x1ffl. Therefore, the _10 compare cannot be folded, and the memmove call remains. I think the missed optimization and the overall problem stems from the fact that optimizers don't know the actual range of _M_offset. Ensuring it's visibly normalized at uses in which out-of-range _M_offsets might sneak in might be enough to avoid the warning and enable further optimizations.
[Bug middle-end/112359] [14 Regression] ICE: in expand_fn_using_insn, at internal-fn.cc:215 with -O -ftree-loop-if-convert -mavx512fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112359
--- Comment #3 from rguenther at suse dot de ---
On Mon, 6 Nov 2023, rdapp at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112359
>
> --- Comment #2 from Robin Dapp ---
> Would something like
>
> + bool allow_cond_op = flag_tree_loop_vectorize
> +&& !gimple_bb (phi)->loop_father->dont_vectorize;
>
> in convert_scalar_cond_reduction be sufficient or are the more conditions to
> check still? Testing with the above and the reduced testcase worked FWIW.
You want, in tree_if_conversion (), remember whether we versioned the
loop as part of
if (need_to_lower_bitfields
|| need_to_predicate
|| any_complicated_phi
|| flag_tree_loop_if_convert != 1)
{
...
and pass that as flag to combine_blocks and down to
predicate_all_scalar_phis (or add a new global flag). Ideally we'd
do the convert_scalar_cond_reduction analysis beforehand and force
versioning for the case we'd generate a .COND_* instead of deciding
at code-generation only (when it's too late to do the required
versioning).
[Bug libstdc++/110807] [13 Regression] Copy list initialisation of a vector raises a warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110807 --- Comment #12 from Jonathan Wakely --- I don't think _M_offset can ever be out of range, it's always set by the library code. Doesn't the warning come from this line, which doesn't use _M_offset anyway? _Bit_type* __q = std::copy(__first._M_p, __last._M_p, __result._M_p); So I'm not sure what we can do in the library to state the invariants in a way the optimizer can understand them.
[Bug middle-end/110859] New FAIL: 23_containers/vector/bool/110807.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110859 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-11-06 --- Comment #4 from Jonathan Wakely --- bug 110807 comment 11 has some analysis of this failure (which I admittedly don't understand).
[Bug tree-optimization/112404] [14 Regression] 521.wrf_r fails to build with internal compiler error: in get_vectype_for_scalar_type, at tree-vect-stmts.cc:13311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112404 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:3cc9ad41db87fb85b13a56bff1f930c258542a70 commit r14-5154-g3cc9ad41db87fb85b13a56bff1f930c258542a70 Author: Richard Biener Date: Mon Nov 6 12:43:11 2023 +0100 tree-optimization/112404 - two issues with SLP of .MASK_LOAD The following fixes an oversight in vect_check_scalar_mask when the mask is external or constant. When doing BB vectorization we need to provide a group_size, best via an overload accepting the SLP node as argument. When fixed we then run into the issue that we have not analyzed alignment of the .MASK_LOADs because they were not identified as loads by vect_gather_slp_loads. Fixed by reworking the detection. PR tree-optimization/112404 * tree-vectorizer.h (get_mask_type_for_scalar_type): Declare overload with SLP node argument. * tree-vect-stmts.cc (get_mask_type_for_scalar_type): Implement it. (vect_check_scalar_mask): Use it. * tree-vect-slp.cc (vect_gather_slp_loads): Properly identify loads also for nodes with children, like .MASK_LOAD. * tree-vect-loop.cc (vect_analyze_loop_2): Look at the representative for load nodes and check whether it is a grouped access before looking for load-lanes support. * gfortran.dg/pr112404.f90: New testcase.
[Bug tree-optimization/112404] [14 Regression] 521.wrf_r fails to build with internal compiler error: in get_vectype_for_scalar_type, at tree-vect-stmts.cc:13311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112404 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 --- Comment #1 from Richard Biener --- Possibly the same as PR112359?
[Bug tree-optimization/111950] [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950 --- Comment #11 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:bf72d50d16f0c1fa8102ca2544d2a05772f8c273 commit r14-5155-gbf72d50d16f0c1fa8102ca2544d2a05772f8c273 Author: Richard Biener Date: Fri Nov 3 14:24:10 2023 +0100 tree-optimization/111950 - vectorizer loop copying The following simplifies LC-PHI arg population during epilog peeling, thereby fixing the testcase in this PR. PR tree-optimization/111950 * tree-vect-loop-manip.cc (slpeel_duplicate_current_defs_from_edges): Remove. (find_guard_arg): Likewise. (slpeel_update_phi_nodes_for_guard2): Likewise. (slpeel_tree_duplicate_loop_to_edge_cfg): Remove calls to slpeel_duplicate_current_defs_from_edges, do not elide LC-PHIs for invariant values. (vect_do_peeling): Materialize PHI arguments for the edge around the epilog from the PHI defs of the main loop exit. * gcc.dg/torture/pr111950.c: New testcase.
[Bug tree-optimization/110641] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023 since r14-2230-g7e904d6c7f2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110641 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Jan Hubicka --- mine.
[Bug target/112405] GCN: "gcc.dg/vect/vect-simd-clone-20.c:22:1: error: conversion of register to a different size in 'view_convert_expr'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112405 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2023-11-06 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug tree-optimization/111950] [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Richard Biener --- Fixed.
[Bug tree-optimization/111000] [14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r14-2944-g3d48c11ad08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111000 Bug 111000 depends on bug 111950, which changed state. Bug 111950 Summary: [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/112405] GCN: "gcc.dg/vect/vect-simd-clone-20.c:22:1: error: conversion of register to a different size in 'view_convert_expr'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112405 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:9125969086bfa1bf804b246ea574a2329b06d2c5 commit r14-5158-g9125969086bfa1bf804b246ea574a2329b06d2c5 Author: Richard Biener Date: Mon Nov 6 14:34:07 2023 +0100 tree-optimization/112405 - SIMD clone calls with (loop) mask The following fixes the mask argument generation for SIMD clone calls under either loop masking or when the actual call is not masked but only a inbranch simd clone is available. The issue was that we tried to directly convert the vector mask to the call argument type but SIMD clone masks require 1 or 0 (which could be even float) values for mask elements so we have to resort to a VEC_COND_EXPR to generate them just like we do for regular passing of the mask. PR tree-optimization/112405 * tree-vect-stmts.cc (vectorizable_simd_clone_call): Properly handle invariant and/or loop mask passing.
[Bug target/112405] GCN: "gcc.dg/vect/vect-simd-clone-20.c:22:1: error: conversion of register to a different size in 'view_convert_expr'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112405 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug target/112393] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1208 with -mavx5124fmaps -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112393 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- .
[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954 --- Comment #7 from CVS Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:fad61bf73b3158157a136bf4d9373fc3d9afe319 commit r14-5160-gfad61bf73b3158157a136bf4d9373fc3d9afe319 Author: Joseph Myers Date: Mon Nov 6 15:01:22 2023 + c: Add -std=c23, -std=gnu23, -Wc11-c23-compat options [PR107954] At the June WG14 meeting, WG14 decided it preferred to keep C23 as the informal name for the next revision of the C standard, despite publication not being before 2024 (publication is due in 2024 whether or not technical changes at the January meeting result in an FDIS ballot being needed). At the Cauldron I raised the question of whether we should thus now add option names such as -std=c23 to GCC, and there was support for doing so. Add -std=c23, making -std=c2x a deprecated alias; also add the alias -std=iso9899:2024. Likewise, add -std=gnu23, making -std=gnu2x a deprecated alias, and add -Wc11-c23-compat, making -Wc11-c2x-compat a deprecated alias. Here, I'm generally just adding the new options and making the minimum changes required to do so, with documentation changed to refer to C23 instead of C2X only where directly associated with documentation of these options. It's intended that future changes will update documentation, diagnostics, comments, variable names, testcase names, etc. to refer consistently to C23. When such changes are made, the new tests c23-opts-3.c, c23-opts-5.c and gnu23-opts-2.c are intended to keep using the old option names they are specifically testing, while other tests would start using the c23/gnu23 versions of the names (as well as the tests themselves being renamed). Updating option names is independent of updating to the final __STDC_VERSION__ value. There, the question is whether we should update the value now or wait for the remaining significant features to be implemented first. (I intend to review Martin's tag compatibility patches for GCC 14. I'm not aware of anyone working on #embed - or on the [[unsequenced]] and [[reproducible]] attributes, though support for standard attributes is optional.) Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR c/107954 gcc/ * doc/cpp.texi (__STDC_VERSION__): Refer to -std=c23 and -std=gnu23 instead of -std=c2x and -std=gnu2x. * doc/extend.texi (Attribute Syntax): Refer to C23 and -std=c23 instead of C2x and -std=c2x. * doc/invoke.texi (-Wc11-c23-compat, -std=c23, -std=gnu23) (-std=iso9899:2024): Document, with -Wc11-c2x-compat, -std=c2x and -std=gnu2x as deprecated aliases. Update descriptions of C23. * doc/standards.texi (Standards): Describe C23 with C2X as an old name. gcc/c-family/ * c.opt (Wc11-c2x-compat): Rename to Wc11-c23-compat and make into a deprecated alias of Wc11-c23-compat. (std=c2x): Rename to std=c23 and make into a deprecated alias of std=c23. (std=gnu2x): Rename to std=gnu23 and make into a deprecated alias of std=gnu23. (std=iso9899:2024): New option. Alias of std=c23. * c-lex.cc (interpret_float): Use OPT_Wc11_c23_compat instead of OPT_Wc11_c2x_compat. * c-opts.cc (c_common_handle_option): Use OPT_std_c23 instead of OPT_std_c2x and OPT_std_gnu23 instead of OPT_std_gnu2x. gcc/c/ * c-errors.cc (pedwarn_c11): Use OPT_Wc11_c23_compat instead of OPT_Wc11_c2x_compat. * c-typeck.cc (build_conditional_expr, convert_for_assignment): Use OPT_Wc11_c23_compat instead of OPT_Wc11_c2x_compat. gcc/testsuite/ * gcc.dg/c23-opts-1.c, gcc.dg/c23-opts-2.c, gcc.dg/c23-opts-3.c, gcc.dg/c23-opts-4.c, gcc.dg/c23-opts-5.c, gcc.dg/gnu23-opts-1.c, gcc.dg/gnu23-opts-2.c: New tests.
[Bug fortran/112407] New: [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407
Bug ID: 112407
Summary: [13 Regression] Fix for PR37336 triggers an ICE in
gfc_format_decoder while constructing a vtab
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: trnka at scm dot com
Target Milestone: ---
Created attachment 56515
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56515&action=edit
reproducer with dependencies
Following up on comment 7 in PR109684. This seems to be another issue uncovered
by the finalization overhaul:
commit r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee
Author: Paul Thomas
Date: Sat Mar 18 07:56:23 2023 +
Fortran: Fix bugs and missing features in finalization [PR37336]
2023-03-18 Paul Thomas
The attached test triggers an assert in gfc_format_decoder, at
fortran/error.cc:1078 (on current 13 branch):
0x65cce5 gfc_format_decoder
gcc/fortran/error.cc:1078
0x1b12ed9 pp_format(pretty_printer*, text_info*)
gcc/pretty-print.cc:1475
0x1b030d1 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
gcc/diagnostic.cc:1592
0x6e0127 gfc_report_diagnostic
gcc/fortran/error.cc:890
0x6e0127 gfc_warning
gcc/fortran/error.cc:923
0x6e07e6 gfc_warning(int, char const*, ...)
gcc/fortran/error.cc:954
0x765d5e resolve_procedure_expression
gcc/fortran/resolve.cc:1956
0x765d5e resolve_variable
gcc/fortran/resolve.cc:6066
0x765d5e gfc_resolve_expr(gfc_expr*)
gcc/fortran/resolve.cc:7302
0x7635c9 gfc_resolve_expr(gfc_expr*)
gcc/fortran/resolve.cc:7267
0x7635c9 resolve_structure_cons
gcc/fortran/resolve.cc:1341
0x774521 resolve_values
gcc/fortran/resolve.cc:12802
0x78afd2 do_traverse_symtree
gcc/fortran/symbol.cc:4190
0x76ac7d resolve_types
gcc/fortran/resolve.cc:17941
0x771efc gfc_resolve(gfc_namespace*)
gcc/fortran/resolve.cc:18038
0x760d1e resolve_symbol
gcc/fortran/resolve.cc:16602
0x78afd2 do_traverse_symtree
gcc/fortran/symbol.cc:4190
0x76ab9e resolve_types
gcc/fortran/resolve.cc:17920
0x771efc gfc_resolve(gfc_namespace*)
gcc/fortran/resolve.cc:18038
0x760d1e resolve_symbol
gcc/fortran/resolve.cc:16602
This assert is hit while printing the following warning:
#0 gfc_warning (opt=0,
gmsgid=0x1e55748 "Non-RECURSIVE procedure %qs at %L is possibly calling
itself recursively. Declare it RECURSIVE or use %<-frecursive%>")
In particular, the following line in gfc_format_decoder is failing:
gcc_assert (loc->nextc - loc->lb->line >= 0);
That's because both loc->nextc and loc->lb are 0 here. Walking up the stack, I
have found that this all happens while resolving the structure constructor for
__vtab_ftldynarrayintmodule_Ftldynarrayint. cons->where and cons->expr->where
in resolve_structure_cons both look like the bogus locus causing the assert:
(gdb) p cons->where
$6 = {nextc = 0x0, lb = 0x0}
(gdb) p cons->expr->where
$8 = {nextc = 0x0, lb = 0x0}
Picking the massive commit mentioned above apart into small chunks and
reverting them one by one, I have narrowed the triggering change down to the
following addition to resolve_symbol():
if (!sym->attr.referenced
&& (sym->ts.type == BT_CLASS || sym->ts.type == BT_DERIVED))
{
gfc_expr *final_expr = gfc_lval_expr_from_sym (sym);
if (gfc_is_finalizable (final_expr->ts.u.derived, NULL))
gfc_set_sym_referenced (sym);
gfc_free_expr (final_expr);
}
Specifically, it's the call to gfc_find_derived_vtab() in gfc_is_finalizable()
on the affected module that directly triggers the bug. Two TBPs in the affected
type are directly involved in triggering the assert. Applying the attached hack
works around the issue (by skipping the call to gfc_find_derived_vtab() for the
two affected routines.
FWIW, both affected routines (NewCopyOther and AssignOther) have two arguments
like this:
subroutine NewCopyOther(self, other)
class(ftlDynArrayInt), intent(out) :: self
type(ftlDynArrayInt), intent(in) :: other
impure elemental subroutine AssignOther(self, other)
class(ftlDynArrayInt), intent(inout) :: self
type(ftlDynArrayInt), intent(in):: other
It's always the "other" argument which triggers this, the "self" one never hits
the bit in resolve_symbol() mentioned above. Changing "other" to
class(ftlDynArrayInt) also makes the issue go away.
To reproduce this, unpack the attached tarball (containing the testcase and
three dependency .mod files) and run gfortran -c test-vtab-construct-ice.f90.
The ftlDynArrayInt type hitting the issue is pulled in by the
ChemicalSystemModule, which seems to be a key ingredient. It's a really big
module with dozens of dependencies (so I can't feasibly provide them all) and
the chem
[Bug fortran/112407] [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407 --- Comment #1 from Tomáš Trnka --- Created attachment 56516 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56516&action=edit Hacky patch working around the issue on this testcase
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #24 from Tomáš Trnka --- (In reply to Steve Kargl from comment #23) > If expr->where is pointing to NULL, then something is definitely not > set up correctly or your code is now going through a different code > path in the compiler. Sorry for the delay with testing this, I was busy with other more pressing tasks. It's not that expr->where would be NULL completely, but its components (nextc and lb) are both NULL. > If this is related to setting up the artificial __final_* procedure, > then it might be missing properly setting the locus. This patch > simply sets the locus of the artificial procedure and its arguments > to that of the derived symbol. This might prevent the ICE, but > lead to a bogus error message. Can you test this? Tested, does not change a thing. The error does not seem to directly have anything to do with the __final_*, but with building the __vtab_* using a structure constructor, which is likely happening at a different place as a side effect of Paul's finalization improvements. As this seems to be a different (although possibly related) issue, I have created PR112407 for further follow-up and posted my new observations in there.
[Bug c++/50755] [avr] ICE: tree check: expected class 'constant', have 'unary' (convert_expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50755 --- Comment #5 from Georg-Johann Lay --- (In reply to Roger Sayle from comment #4) > This appears to be fixed on mainline. At least the test case passes on newer versions. For a definite answer you'd have to bisect / find the patch that solved it.
[Bug d/112408] New: [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
Bug ID: 112408
Summary: [12/13/14 regression] d21 loops in getCpuInfo0B in
Solaris/x86 kernel zone
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Host: i386-pc-solaris2.11, x86_64-pc-linux-gnu
Target: i386-pc-solaris2.11, x86_64-pc-linux-gnu
Build: i386-pc-solaris2.11, x86_64-pc-linux-gnu
While preparing GCC builds for a new Solaris 11.4/x86 GCC CFarm system, I
re-ran
into an issue with D programs looping inside a Solaris kernel zone (a VM),
while
the same binaries work fine on bare metal.
I've now managed to root-cause the issue. When bootstrapping e.g. GCC 13 with
GCC 9.5.0 or 11.4.0, configuring libphobos in stage 1 loops. This can be
reproduced with
$ cat conftest.d
module object;
extern(C) int main() {
return 0;
}
$ d21 conftest.d
which loops indefinitely. d21 show the following stacktrace:
Thread 2 received signal SIGINT, Interrupt.
[Switching to Thread 1 (LWP 1)]
_D4core5cpuid12getCpuInfo0BFNbNiNeZv ()
at gcc-11.4.0/libphobos/libdruntime/core/cpuid.d:669
669 if (b!=0) {
1: x/i $pc
=> 0x442b311 <_D4core5cpuid12getCpuInfo0BFNbNiNeZv+33>: test %ebx,%ebx
(gdb) bt
#0 _D4core5cpuid12getCpuInfo0BFNbNiNeZv ()
at gcc-11.4.0/libphobos/libdruntime/core/cpuid.d:669
#1 0x0442b7e3 in _D4core5cpuid8cpuidX86FNbNiNeZv ()
at gcc-11.4.0/libphobos/libdruntime/core/cpuid.d:953
#2 0x0442bd75 in _D4core5cpuid18_sharedStaticCtor1FNbNiNeZv ()
at gcc-11.4.0/libphobos/libdruntime/core/cpuid.d:1073
#3 0x0441a421 in runModuleFuncs (this=0x0, modules=...)
at gcc-11.4.0/libphobos/libdruntime/rt/minfo.d:858
#4 _D2rt5minfo11ModuleGroup8runCtorsMFZv (this=...)
at gcc-11.4.0/libphobos/libdruntime/rt/minfo.d:728
#5 0x0441b5bd in __foreachbody1 (this=, sg=...)
at gcc-11.4.0/libphobos/libdruntime/rt/minfo.d:796
#6 0x0440ffd2 in _D3gcc8sections3elf3DSO7opApplyFMDFKSQBjQBiQBcQBbZiZi
(dg=...)
at gcc-11.4.0/libphobos/libdruntime/gcc/sections/elf.d:106
#7 0x0441a61e in rt_moduleCtor ()
at gcc-11.4.0/libphobos/libdruntime/rt/minfo.d:793
#8 0x0440f880 in rt_init ()
at gcc-11.4.0/libphobos/libdruntime/rt/dmain2.d:129
#9 0x022f4c16 in d_init_options (decoded_options=0x47e1f00)
at gcc-13.2.0/gcc/d/d-lang.cc:290
#10 0x02ac5fbc in toplev::main (this=0x7fffb97a, argc=2,
argv=0x7fffb9b8) at gcc-13.2.0/gcc/toplev.cc:2240
#11 0x04301c46 in main (argc=2, argv=0x7fffb9b8)
at gcc-13.2.0/gcc/main.cc:39
Running getCpuInfo0B side-by-side in the kernel zone and on bare metal shows:
kernel zone bare metal
level 0
a 0 1
b 1 2
level 1
a 0 5
b 1 28
level 2
a 0 0
b 1 0
and so on for each higher level. So inside a kernel zone, a!=0 || b!=0 remains
true, explaining the loop.
If I'm reading the spec (Intel® 64 and IA-32 Architectures
Software Developer’s Manual, Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B,
3C, 3D, and 4, Order Number: 325462-081US, September 2023, Vol. 2A,
3-225, p.821) correctly, this is a bug in the kernel zone software:
A sub-leaf returning an invalid domain always returns 0 in EAX and EBX.
OTOH I don't see why getCpuInfo0B needs to loop here since it's only interested
in levels 0 and 1 anyway.
This affects all DMD-based versions of GDC, while the previous C++-based
versions
are fine.
[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408 Rainer Orth changed: What|Removed |Added Target Milestone|--- |14.0
[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #1 from ibuclaw at gcc dot gnu.org --- (In reply to Rainer Orth from comment #0) > This affects all DMD-based versions of GDC, while the previous C++-based > versions > are fine. The compiler is fine, but if I understand right, all programs built by the C++-based version would still observe the same infinite loop.
[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from ibuclaw at gcc dot gnu.org --- > (In reply to Rainer Orth from comment #0) >> This affects all DMD-based versions of GDC, while the previous C++-based >> versions >> are fine. > The compiler is fine, but if I understand right, all programs built by the > C++-based version would still observe the same infinite loop. Just the opposite: both D-based d21 and every D program somehow using getCpuInfo0B would experience the loop. I believe I originally experienced that in early (GCC 8 or 9) versions when testing libphobos in a Solaris 11.3 kernel zone.
[Bug c/112409] New: Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409
Bug ID: 112409
Summary: Structure is not initialized as expected
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: freddy77 at gmail dot com
Target Milestone: ---
I was writing a small network utility till I found a weird behaviour computing
TCP checksums. After some debugging I found that the error disappeared with
either -O1 or -O0. So I reduced the program, trying using multiple GCC versions
and it kept happening.
The final program (stripped down) is:
typedef long unsigned int size_t;
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
#define ntohs __builtin_bswap16
#define htonl __builtin_bswap32
static inline unsigned
reduce_cksum(unsigned sum)
{
return (sum >> 16) + (sum & 0xu);
}
static unsigned
cksum(const void *pkt, size_t len, unsigned int start)
{
const uint16_t *data = (const uint16_t *) pkt;
unsigned sum = start;
for (; len >= 2; len -= 2)
sum += *data++;
if (len)
sum += ntohs(*((const uint8_t *)data) << 8);
sum = reduce_cksum(sum);
sum = reduce_cksum(sum);
return sum;
}
static unsigned
tcpdump_flow_new(uint32_t saddr, uint32_t daddr)
{
struct {
uint32_t saddr, daddr;
uint8_t zero, proto;
} pseudo = { htonl(saddr), htonl(daddr), 0, 6 };
return cksum(&pseudo, 10, 0);
}
int main(void)
{
unsigned res = tcpdump_flow_new(0x01020304, 0xa1b2c3d4);
return res;
}
Using -O2 option and Compiler Explorer (but I tried multiple versions locally)
produced this:
main:
xor edx, edx
lea rax, [rsp-12]
lea rsi, [rsp-2]
.L2:
movzx ecx, WORD PTR [rax]
add rax, 2
add edx, ecx
cmp rax, rsi
jne .L2
mov eax, edx
movzx edx, dx
shr eax, 16
add edx, eax
mov eax, edx
movzx edx, dx
shr eax, 16
add eax, edx
ret
It's easy to spot that the constants disappeared from the code and program uses
not initialized memory.
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- You have an aliasing violation with uint8_t <-> uint32_t. Works with -fno-strict-aliasing.
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 --- Comment #2 from Andrew Pinski --- I have to double check but I am 99% sure this code is undefined due to alias violations. Use either memcpy or -fno-strict-aliasing.
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409
--- Comment #3 from Jonathan Wakely ---
(In reply to Frediano Ziglio from comment #0)
> static unsigned
> cksum(const void *pkt, size_t len, unsigned int start)
> {
> const uint16_t *data = (const uint16_t *) pkt;
> unsigned sum = start;
>
> for (; len >= 2; len -= 2)
> sum += *data++;
Right, this is undefined behaviour, because you're reading uint16_t values from
an object that is not a uint16_t.
[Bug tree-optimization/111572] [14 Regression] Wrong code at -O2 on x86_64-linux-gnu since r14-301-gf2d6beb7a4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111572 --- Comment #6 from Martin Jambor --- (In reply to Andrew Pinski from comment #5) > Hmm, this works on the trunk now. Would be a good idea to figure out what > "fixed" it. If my simple test is correct, the error disappeared with r14-4790-g9692309ed6b625 (Richi's: tree-optimization/111445 - simple_iv simplification fault)
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jonathan Wakely --- There's a reason that the bug reporting guidelines *and* the banner at the top of the bug creation form ask you to try -fno-strict-aliasing, and it's easy to see that the constants are not removed if you use that option. Like the guidelines and the banner say, if -fno-strict-aliasing makes a difference, your code is probably not correct.
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 Frediano Ziglio changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from Frediano Ziglio --- But the pointer "passes" through a "void*" conversion, so there should be no aliasing. Or am I missing something? So what's the standard C way to avoid this (without using specific compiler options) ?
[Bug target/112397] Two persistent libstdc++ test failures on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397 Iain Sandoe changed: What|Removed |Added Component|libstdc++ |target --- Comment #2 from Iain Sandoe --- (In reply to Jonathan Wakely from comment #1) > The .cold symbol is created by gcc, I don't see any way to control its > visibility in the source. So maybe a target bug in the compiler, not a > library bug. Agreed its a target issue - it's a question of convincing the linker that the label is not reachable from a different TU if the implementation of the non-cold symbol comes from that.
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Jonathan Wakely --- (In reply to Frediano Ziglio from comment #5) > But the pointer "passes" through a "void*" conversion, so there should be no > aliasing. Or am I missing something? That's not how aliasing works. You can't just cast to void* to change the effective type of that struct and magically make it valid to read uint16_t values from it. > So what's the standard C way to avoid this (without using specific compiler > options) ? memcpy GCC will also allow you to use a union, but the union has to be visible in the code that performs the type punning.
[Bug c++/112410] New: error when auto(x) is used in a variable initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112410 Bug ID: 112410 Summary: error when auto(x) is used in a variable initializer Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vanyacpp at gmail dot com Target Milestone: --- int x = auto(42); // OK int y(auto(42)); // error On the second line GCC -std=c++23 gives an error: error: non-function 'y' declared as implicit template I believe the code is correct and should compile without errors.
[Bug c++/112410] error when auto(x) is used in a variable initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112410
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
CC||mpolacek at gcc dot gnu.org
Last reconfirmed||2023-11-06
Status|UNCONFIRMED |NEW
--- Comment #1 from Marek Polacek ---
I think you're right. Same for
int z(auto{42});
[Bug c++/112410] error when auto(x) is used in a variable initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112410 --- Comment #2 from Andrew Pinski --- Confirmed. Looks like GCC is messing the Most vexing parse here.
[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
--- Comment #3 from ibuclaw at gcc dot gnu.org ---
Based on what I see here, this patch to core.cpuid should be sufficient to fix
loop and not introduce any change in existing behaviour.
---
--- a/druntime/src/core/cpuid.d
+++ b/druntime/src/core/cpuid.d
@@ -666,10 +666,12 @@ void getAMDcacheinfo()
// to determine number of processors.
void getCpuInfo0B()
{
-int level=0;
int threadsPerCore;
uint a, b, c, d;
-do {
+// I'm not sure about this. The docs state that there
+// are 2 hyperthreads per core if HT is factory enabled.
+for (int level = 0; level < 2; level++)
+{
version (GNU_OR_LDC) asm pure nothrow @nogc {
"cpuid" : "=a" (a), "=b" (b), "=c" (c), "=d" (d) : "a" (0x0B), "c"
(level);
} else asm pure nothrow @nogc {
@@ -681,19 +683,20 @@ void getCpuInfo0B()
mov c, ECX;
mov d, EDX;
}
-if (b!=0) {
- // I'm not sure about this. The docs state that there
- // are 2 hyperthreads per core if HT is factory enabled.
-if (level==0)
+if (b != 0)
+{
+if (level == 0)
threadsPerCore = b & 0x;
-else if (level==1) {
+else if (level == 1)
+{
cpuFeatures.maxThreads = b & 0x;
cpuFeatures.maxCores = cpuFeatures.maxThreads /
threadsPerCore;
}
-
}
-++level;
-} while (a!=0 || b!=0);
+// Got "invalid domain" returned from cpuid
+if (a == 0 && b == 0)
+break;
+}
}
void cpuidX86()
[Bug c++/112410] error when auto(x) is used in a variable initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112410 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Part of the problem seems to be that fully_implicit_function_template_p is set. I'd like to poke more.
[Bug libstdc++/108409] std::chrono::current_zone() doesn't work on AIX or Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108409 Mike Crowe changed: What|Removed |Added CC||mac at mcrowe dot com --- Comment #7 from Mike Crowe --- ICU tries to solve this problem with a table at https://github.com/unicode-org/icu/blob/fa6a4661ba002c1c1ee68cbf5c7ac9af75132d07/icu4c/source/common/putil.cpp#L802 and other heuristics in the same file. Based on my understanding, the table is incorrect for the Australian zones and US/Aleutian (it gets the short names wrong) and it's missing the non-DST US zones. I'm not sure if it's worth going to these lengths to try to map POSIX time zone strings to Olson names, but I thought I'd provide the link in case it's useful.
[Bug tree-optimization/112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX (b, max) into max = MAX (ABS(b), max)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112324 --- Comment #3 from Andrew Pinski --- Note a simple patch to improve phiopt here does not improve the original code in openjpeg. The reason why is due to the code in phiopt here is only operates on the case where the phi would be the only one. In that case we also have a vop phi which changes which causes the code not to be done.
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 --- Comment #7 from Frediano Ziglio --- Sorry for the noise, thanks for the informations. I didn't notice banner on top. I went back and I notice it, pretty small and it looks like a lot of other website banners for technical disruptions or cookies.
[Bug tree-optimization/112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX (b, max) into max = MAX (ABS(b), max)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112324 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > Note a simple patch to improve phiopt here does not improve the original > code in openjpeg. > > The reason why is due to the code in phiopt here is only operates on the > case where the phi would be the only one. In that case we also have a vop > phi which changes which causes the code not to be done. But maybe ifcvt could use the same function to do the transformation before it does the conversion ...
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #31 from Andreas Schwab --- For the first time the bootstrap time has been reduced, from 192543 (20231028) to 141231 (20231103), -26,6%.
[Bug libgcc/65833] Attempting to convert 128 bit integers to 128 bit decimal floating-point results in an unresolved symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65833 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2023-11-06 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 56517 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56517&action=edit gcc14-pr65833.patch Untested implementation (on top of _BitInt support, so for now x86_64 only, but with the hope that other int128 targets will gain _BitInt support soon).
[Bug target/112411] New: ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411 Bug ID: 112411 Summary: ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu Product: gcc Version: 14.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: powerpc64le-unknown-linux-gnu Created attachment 56518 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56518&action=edit reduced testcase Compiler output: $ powerpc64le-unknown-linux-gnu-gcc --param=min-nondebug-insn-uid=2147483647 testcase.c -wrapper valgrind,-q,--num-callers=100 ==18938== Invalid read of size 4 ==18938==at 0xC9A477: get_attr_length_1(rtx_insn*, int (*)(rtx_insn*)) (final.cc:353) ==18938==by 0x1489717: rs6000_insn_cost (rs6000.cc:22634) ==18938==by 0x1489717: rs6000_insn_cost(rtx_insn*, bool) (rs6000.cc:22614) ==18938==by 0xC6D69E: canonicalize_comparison(machine_mode, rtx_code*, rtx_def**) (expmed.cc:6344) ==18938==by 0xC6DD71: emit_store_flag_1(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode, int, int, machine_mode) (expmed.cc:5629) ==18938==by 0xC6E2A7: emit_store_flag(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode, int, int) (expmed.cc:6037) ==18938==by 0xC6F26A: emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode, int, int) (expmed.cc:6177) ==18938==by 0xC89B8F: convert_mode_scalar(rtx_def*, rtx_def*, int) (expr.cc:689) ==18938==by 0xC7E70D: expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) (expr.cc:9396) ==18938==by 0xB4A2F0: expand_gimple_stmt_1 (cfgexpand.cc:3983) ==18938==by 0xB4A2F0: expand_gimple_stmt(gimple*) (cfgexpand.cc:4044) ==18938==by 0xB5067E: expand_gimple_basic_block(basic_block_def*, bool) (cfgexpand.cc:6100) ==18938==by 0xB5235E: (anonymous namespace)::pass_expand::execute(function*) (cfgexpand.cc:6835) ==18938==by 0xF7B62A: execute_one_pass(opt_pass*) (passes.cc:2641) ==18938==by 0xF7BF0F: execute_pass_list_1(opt_pass*) (passes.cc:2750) ==18938==by 0xF7BF48: execute_pass_list(function*, opt_pass*) (passes.cc:2761) ==18938==by 0xB92FF5: expand (cgraphunit.cc:1841) ==18938==by 0xB92FF5: cgraph_node::expand() (cgraphunit.cc:1794) ==18938==by 0xB93F09: output_in_order (cgraphunit.cc:2191) ==18938==by 0xB93F09: symbol_table::compile() [clone .part.0] (cgraphunit.cc:2395) ==18938==by 0xB96EA7: compile (cgraphunit.cc:2311) ==18938==by 0xB96EA7: symbol_table::finalize_compilation_unit() (cgraphunit.cc:2583) ==18938==by 0x10B3D62: compile_file() (toplev.cc:473) ==18938==by 0x9B8903: do_compile (toplev.cc:2129) ==18938==by 0x9B8903: toplev::main(int, char**) (toplev.cc:2285) ==18938==by 0x9BA00A: main (main.cc:39) ==18938== Address 0xfffe001c is not stack'd, malloc'd or (recently) free'd ==18938== during RTL pass: expand testcase.c: In function 'foo': testcase.c:7:5: internal compiler error: Segmentation fault 7 | i += j; | ^~ $ powerpc64le-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5141-20231106022717-g1a55724f787-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/14.0.0/lto-wrapper Target: powerpc64le-unknown-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 --with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu --with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld --with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-5141-20231106022717-g1a55724f787-checking-yes-rtl-df-extra-powerpc64le Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231106 (experimental) (GCC)
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #25 from Steve Kargl --- On Mon, Nov 06, 2023 at 03:34:42PM +, trnka at scm dot com wrote: > > If expr->where is pointing to NULL, then something is definitely not > > set up correctly or your code is now going through a different code > > path in the compiler. > > Sorry for the delay with testing this, I was busy with other more pressing > tasks. No problem. I have very limited time to look at gfortran bugs and yours caught my eye. > It's not that expr->where would be NULL completely, but its components (nextc > and lb) are both NULL. Sorry about that. I did mean to say the components not just expr->where. In any event, the locus is clearly not correct. > > If this is related to setting up the artificial __final_* procedure, > > then it might be missing properly setting the locus. This patch > > simply sets the locus of the artificial procedure and its arguments > > to that of the derived symbol. This might prevent the ICE, but > > lead to a bogus error message. Can you test this? > > Tested, does not change a thing. The error does not seem to directly have > anything to do with the __final_*, but with building the __vtab_* using a > structure constructor, which is likely happening at a different place as > a side effect of Paul's finalization improvements. Bummer. I was hoping that it would give a better pointer to where gfortran needs to handle the locus. > As this seems to be a different (although possibly related) issue, > I have created PR112407 for further follow-up and posted my new > observations in there. I saw the new PR. Thanks for the in depth analysis. In setting up the constructor for a __vtab_* (an internal symbol), we likely need to ensure the locus is properly set in each list member.
[Bug target/110551] [11/12/13/14 Regression] an extra mov when doing 128bit multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110551 --- Comment #9 from Moncef Mechri --- With Roger's latest patch, codegen looks good with -O2 and -O2 -march=haswell. Thanks! I think this can be marked as resolved?
[Bug libfortran/112412] New: Masked reduction functions return an unallocated array when the result is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112412 Bug ID: 112412 Summary: Masked reduction functions return an unallocated array when the result is empty Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org Target Milestone: --- Non-masked reduction functions work, but their masked variant don't allocate if the result is empty, so the result is seen as non-allocated. See: https://gcc.gnu.org/pipermail/fortran/2023-November/059902.html
[Bug c/112413] New: Wrong switch jump table offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413
Bug ID: 112413
Summary: Wrong switch jump table offset
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.riviere at freesbee dot fr
Target Milestone: ---
In some circumstances, gcc produces bad code for switch instruction.
Main goal of the testcase is to force gcc to produce a jump table.
$ cat swi.c
int g;
void f(int i)
{
switch (i)
{
case 0: g = 6082; break;
case 1: g = 9332; break;
case 2: g = 5642; break;
case 3: g = 1423; break;
case 4: g = 2152; break;
case 5: g = 6779; break;
case 6: g = 7074; break;
case 7: g = 8280; break;
}
}
$ m68k-linux-gcc -Os -S -o - swi.c -mlong-jump-table-offsets -malign-int
#NO_APP
.file "swi.c"
.text
.align 2
.globl f
.type f, @function
f:
move.l 4(%sp),%d0
moveq #7,%d1
cmp.l %d0,%d1
jcs .L1
lsl.l #2,%d0
move.l .L4(%pc,%d0.l),%d0
jmp %pc@(2,%d0:l)
.balignw 4,0x284c |Potential bug here
.L4:
.long .L11-.L4
.long .L10-.L4
.long .L9-.L4
.long .L8-.L4
.long .L7-.L4
.long .L6-.L4
.long .L5-.L4
.long .L3-.L4
.L11:
move.l #6082,g
.L1:
rts
.L10:
move.l #9332,g
jra .L1
...
As the jmp may not be aligned on a multiple of 4, the .balignw directive may
introduce a 2-byte filler, causing jmp to use a wrong offset.
Same happens with m68k-elf-gcc.
[Bug target/112413] Wrong switch jump table offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #1 from Andrew Pinski --- I don't see any issues with the output of gcc. Are you sure this is not a binutils gnu as issue where the offsets are done incorrectly there.
[Bug target/112413] Wrong switch jump table offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413 --- Comment #2 from Vincent Riviere --- Cause is in gcc/config/m68k/linux.h, macro ASM_RETURN_CASE_JUMP: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/m68k/linux.h;h=2e1cb5498b86f053d1e9b7c530648dfa186ca4c4;hb=HEAD#l96 jmp %%pc@(2,%0:w) Offset 2 is hardcoded in the macro. Ideally, it should be replaced with the label of the first jump table entry. But I guess it isn't possible inside that macro. A solution is to force ADDR_VEC_ALIGN to 0, in order to completely disable the jump table alignment. That's consistent with ASM_RETURN_CASE_JUMP expectations. #define ADDR_VEC_ALIGN(ADDR_VEC) 0 This should be done for all m68k targets.
[Bug c++/112414] New: Does gcc need __builtin_assume_separate_storage?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112414 Bug ID: 112414 Summary: Does gcc need __builtin_assume_separate_storage? Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- clang provides a new builtin since clang 17 for __builtin_assume_separate_storage. Does GCC need it?
[Bug c++/112414] Does gcc need __builtin_assume_separate_storage?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112414 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX (b, max) into max = MAX (ABS(b), max)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112324 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > (In reply to Andrew Pinski from comment #3) > > Note a simple patch to improve phiopt here does not improve the original > > code in openjpeg. > > > > The reason why is due to the code in phiopt here is only operates on the > > case where the phi would be the only one. In that case we also have a vop > > phi which changes which causes the code not to be done. > > But maybe ifcvt could use the same function to do the transformation before > it does the conversion ... I will try to figure that out next but I want to get this patch though.
[Bug tree-optimization/111472] [11/12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu since r11-4563-gd0d8b5d836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111472 --- Comment #3 from Andrew Macleod --- I'm not sure that this didn't uncover something elsewhere, possibly ivopts since that pass seems to be generating something different and I think there were some fixes put in there on trunk?. Regardless, this currently works on trunk. Can we run a regression on trunk and see what patch fixed it? Andrew
[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-11-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- There are also a few cases where null(null()) is erroneously rejected: program p implicit none integer, pointer :: x call foo (null (x))! valid and accepted call foo (null ()) ! valid and accepted call foo (null (null (x))) ! valid but rejected call foo (null (null ())) ! valid but rejected contains subroutine foo (y) integer, pointer :: y end subroutine foo end
[Bug tree-optimization/111472] [11/12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu since r11-4563-gd0d8b5d836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111472 --- Comment #4 from Andrew Macleod --- (In reply to Andrew Macleod from comment #3) > I'm not sure that this didn't uncover something elsewhere, possibly ivopts > since that pass seems to be generating something different and I think there > were some fixes put in there on trunk?. > > Regardless, this currently works on trunk. Can we run a regression on trunk > and see what patch fixed it? > > Andrew And still fails on GCC13, so it appears to have been a trunk patch that fixed it.
[Bug tree-optimization/111472] [11/12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu since r11-4563-gd0d8b5d836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111472 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Macleod from comment #3) > I'm not sure that this didn't uncover something elsewhere, possibly ivopts > since that pass seems to be generating something different and I think there > were some fixes put in there on trunk?. > > Regardless, this currently works on trunk. Can we run a regression on trunk > and see what patch fixed it? Most likely r14-4789-g44e7e4498c (aka PR 110243).
[Bug target/112413] Wrong switch jump table offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413
--- Comment #3 from Vincent Riviere ---
(In reply to Andrew Pinski from comment #1)
> I don't see any issues with the output of gcc. Are you sure this is not a
> binutils gnu as issue where the offsets are done incorrectly there.
Yes, I'm sure it's a gcc bug.
With the testcase I initially provided, by chance it's the favourable case.
But if I artificially add a misalignment with a nop, for example, the wrong
result appears:
$ cat swi2.c
int g;
void f(int i)
{
asm("nop");
switch (i)
{
case 0: g = 6082; break;
case 1: g = 9332; break;
case 2: g = 5642; break;
case 3: g = 1423; break;
case 4: g = 2152; break;
case 5: g = 6779; break;
case 6: g = 7074; break;
case 7: g = 8280; break;
}
}
$ m68k-linux-gcc -Os -c swi2.c -mlong-jump-table-offsets -malign-int
$ m68k-linux-objdump -d swi2.o
swi2.o:file format elf32-m68k
Disassembly of section .text:
:
0: 202f 0004 movel %sp@(4),%d0
4: 4e71nop
6: 7207moveq #7,%d1
8: b280cmpl %d0,%d1
a: 6536bcss 42
c: e588lsll #2,%d0
e: 203b 0808 movel %pc@(18 ,%d0:l),%d0 |right offset
12: 4efb 0802 jmp %pc@(16 ,%d0:l) |wrong offset
16: 284cmoveal %a4,%a4 |harmful filler
18: 0020 orib #32,%d0
1c: 002c orib #44,%d0
20: 0038 orib #56,%d0
See that:
- actual jump table starts at offset 0x18
- at offset 0x16, a useless "moveal %a4,%a4" instruction is inserted as filler
- at offset 0xe, offset 0x18 is used appropriately for label .L4. So the right
jump table entry is properly read.
- but at offset 0x12, a *wrong* offset 0x16 is used for the jump. That's
actually the offset of the filler, while it should be 0x18 for label .L4.
This can't work:
- the jump table offsets are computed from the start of the jump table
- but jmp, with that "2" hardcoded as offset, expects offsets being relative to
the address right after itself.
So if a filler is inserted between jmp and actual table contents, as in the
example above, the jump occurs to a wrong address.
[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819 --- Comment #3 from anlauf at gcc dot gnu.org --- Created attachment 56519 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56519&action=edit Partial patch This patch adjusts the checking so that nested NULL()s are accepted, tries to implement Interp J3/22-146 when passing NULL() to an assumed-rank dummy, and catches NULL() passed to an assumed-length dummy. TODO: fix handling of NULL(mold) in gfc_conv_procedure_call.
[Bug rtl-optimization/112415] New: [14 regression] Python 3.11 miscompiled with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
Bug ID: 112415
Summary: [14 regression] Python 3.11 miscompiled with new RTL
fold mem offset pass, since r14-4664-g04c9cf5c786b94
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
CC: danglin at gcc dot gnu.org, manolis.tsamis at vrull dot eu
Target Milestone: ---
I've bisected this twice and come to r14-4664-g04c9cf5c786b94 ('Implement new
RTL optimizations pass: fold-mem-offsets'). -fno-fold-mem-offsets makes things
work.
Python 3.11.6 fails to build on HPPA since that commit with the built-Python
segfaulting during the build.
```
hppa2.0-unknown-linux-gnu-gcc -c -Wsign-compare -DNDEBUG -O2 -pipe
-march=2.0 -fdiagnostics-color=always -frecord-gcc-switches -ggdb3 -fwrapv
-std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-init
ializers -Wstrict-prototypes -Werror=implicit-function-declaration
-fvisibility=hidden -I./Include/internal -I. -I./Include
-I/usr/include/ncursesw -fPIC -DPy_BUILD_CORE -o Python/frozen.o
Python/frozen.c
./_bootstrap_python ./Tools/scripts/deepfreeze.py \
Python/frozen_modules/importlib._bootstrap.h:importlib._bootstrap \
Python/frozen_modules/importlib._bootstrap_external.h:importlib._bootstrap_external
\
Python/frozen_modules/zipimport.h:zipimport \
Python/frozen_modules/abc.h:abc \
Python/frozen_modules/codecs.h:codecs \
Python/frozen_modules/io.h:io \
Python/frozen_modules/_collections_abc.h:_collections_abc \
Python/frozen_modules/_sitebuiltins.h:_sitebuiltins \
Python/frozen_modules/genericpath.h:genericpath \
Python/frozen_modules/ntpath.h:ntpath \
Python/frozen_modules/posixpath.h:posixpath \
Python/frozen_modules/os.h:os \
Python/frozen_modules/site.h:site \
Python/frozen_modules/stat.h:stat \
Python/frozen_modules/importlib.util.h:importlib.util \
Python/frozen_modules/importlib.machinery.h:importlib.machinery \
Python/frozen_modules/runpy.h:runpy \
Python/frozen_modules/__hello__.h:__hello__ \
Python/frozen_modules/__phello__.h:__phello__ \
Python/frozen_modules/__phello__.ham.h:__phello__.ham \
Python/frozen_modules/__phello__.ham.eggs.h:__phello__.ham.eggs \
Python/frozen_modules/__phello__.spam.h:__phello__.spam \
Python/frozen_modules/frozen_only.h:frozen_only \
-o Python/deepfreeze/deepfreeze.c
make: *** [Makefile:1298: Python/deepfreeze/deepfreeze.c] Segmentation fault
(core dumped)
make: *** Waiting for unfinished jobs
hppa2.0-unknown-linux-gnu-gcc -c -I./Modules/_decimal/libmpdec -DCONFIG_32=1
-DANSI=1 -Wsign-compare -DNDEBUG -O2 -pipe -march=2.0
-fdiagnostics-color=always -frecord-gcc-switches -ggdb3 -fwrapv -std=c11
-Wextra -Wno-unused-parameter -Wno-missing-field-initializers
-Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden
-I./Include/internal -I. -I./Include -I/usr/include/ncursesw -fPIC -fPIC -o
Modules/_decimal/libmpdec/mpdecimal.o ./Modules/_decimal/libmpdec/mpdecimal.c
* ERROR: dev-lang/python-3.11.6::gentoo failed (compile phase):
* emake failed
```
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 Sam James changed: What|Removed |Added Summary|[14 regression] Python 3.11 |[14 regression] Python 3.11 |miscompiled with new RTL|miscompiled on HPPA with |fold mem offset pass, since |new RTL fold mem offset |r14-4664-g04c9cf5c786b94|pass, since ||r14-4664-g04c9cf5c786b94 --- Comment #1 from Sam James --- Backtrace from the crashing Python: ``` (gdb) r Starting program: /var/tmp/portage/dev-lang/python-3.11.6/work/Python-3.11.6/_bootstrap_python ./Tools/scripts/deepfreeze.py Python/frozen_modules/importlib._bootstrap.h:importlib._bootstrap Python/frozen_modules/importlib._bootstrap_external.h:importlib._bootstrap_external Python/frozen_modules/zipimport.h:zipimport Python/frozen_modules/abc.h:abc Python/frozen_modules/codecs.h:codecs Python/frozen_modules/io.h:io Python/frozen_modules/_collections_abc.h:_collections_abc Python/frozen_modules/_sitebuiltins.h:_sitebuiltins Python/frozen_modules/genericpath.h:genericpath Python/frozen_modules/ntpath.h:ntpath Python/frozen_modules/posixpath.h:posixpath Python/frozen_modules/os.h:os Python/frozen_modules/site.h:site Python/frozen_modules/stat.h:stat Python/frozen_modules/importlib.util.h:importlib.util Python/frozen_modules/importlib.machinery.h:importlib.machinery Python/frozen_modules/runpy.h:runpy Python/frozen_modules/__hello__.h:__hello__ Python/frozen_modules/__phello__.h:__phello__ Python/frozen_modules/__phello__.ham.h:__phello__.ham Python/frozen_modules/__phello__.ham.eggs.h:__phello__.ham.eggs Python/frozen_modules/__phello__.spam.h:__phello__.spam Python/frozen_modules/frozen_only.h:frozen_only -o Python/deepfreeze/deepfreeze.c warning: File "/usr/lib/libthread_db.so.1" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /usr/lib/libthread_db.so.1 line to your configuration file "/root/.config/gdb/gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/root/.config/gdb/gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. Program received signal SIGSEGV, Segmentation fault. 0x412083fc in _PyST_GetSymbol (name=0xf9a33a60, ste=) at Python/symtable.c:396 396 PyObject *v = PyDict_GetItemWithError(ste->ste_symbols, name); (gdb) bt #0 0x412083fc in _PyST_GetSymbol (name=0xf9a33a60, ste=) at Python/symtable.c:396 #1 _PyST_GetScope (ste=, name=0xf9a33a60) at Python/symtable.c:406 #2 0x411bb8f8 in compiler_nameop (c=0xf7b03b88, name=, ctx=Load) at Python/compile.c:4274 #3 0x411be074 in compiler_visit_expr (c=0x1, e=) at Python/compile.c:5969 #4 0x411bcc88 in compiler_visit_expr1 (c=0xf7b03b88, e=0x1) at Python/compile.c:5915 #5 0x411be074 in compiler_visit_expr (c=0x1, e=) at Python/compile.c:5969 #6 0x411bceac in compiler_call (e=0x1, c=0xf7b03b88) at Python/compile.c:4952 #7 compiler_visit_expr1 (c=0xf7b03b88, e=0x1) at Python/compile.c:5905 #8 0x411c1f34 in compiler_visit_expr (e=, c=0xf9a33a60) at Python/compile.c:5969 #9 compiler_decorators (decos=0x8d, c=0xf9a33a60) at Python/compile.c:2327 #10 compiler_class (c=0xf9a33a60, s=0x414e4490) at Python/compile.c:2702 #11 0x411c566c in compiler_body (c=0xf7b03b88, stmts=0xf9a33a60) at Python/compile.c:2180 #12 0x411c7e98 in compiler_mod (mod=0xf7b03b88, c=0x0) at Python/compile.c:2197 #13 _PyAST_Compile (mod=0xf7b03b88, filename=0x8d, flags=, optimize=, arena=) at Python/compile.c:581 #14 0x411fe7b8 in Py_CompileStringObject (str=0xf7b03b88 "\371\240\277\220\371\236\353`\371\257\221\260\367\260:t", filename=0x8d, start=-139445336, flags=0xf9a33a60, optimize=) at Python/pythonrun.c:1799 #15 0x4119c334 in builtin_compile_impl (module=, feature_version=, optimize=, dont_inherit=, flags=, mode=, filename=0xf998db68, source=0x8d) at Python/bltinmodule.c:831 #16 builtin_compile (module=, args=, nargs=, kwnames=) at Python/clinic/bltinmodule.c.h:328 #17 0x410f3ae4 in cfunction_vectorcall_FASTCALL_KEYWORDS (func=0xf9a33a60, args=0x8d, nargsf=, kwnames=) at ./Include/cpython/methodobject.h:52 #18 0x4109fa88 in _PyVectorcall_Call (tstate=0xf7b03b88, func=, callable=0xf9a33a60, tuple=, kwargs=) at Objects/call.c:257 #19 0x4109fd28 in _PyObject_Call (tstate=0xf9a33a60, callable=0x1, args=0xf7b03ba8, kwargs=0x8d) at Objects/call.c:328 #20 0x4109fdb8 in PyObject_Call () at Objects/call.c:352 #21 0x411a47c8 in do_call_core (tstate=0x8d, func=0x1, callargs=0xf9a33a60, kwdict=0
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #2 from Sam James --- I'll grab a bad vs good build directory next and upload both, and then try see which objects differ. Dave, can you reproduce?
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |14.0 Target||hppa2.0-unknown-linux-gnu
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #3 from dave.anglin at bell dot net --- On 2023-11-06 4:00 p.m., sjames at gcc dot gnu.org wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x412083fc in _PyST_GetSymbol (name=0xf9a33a60, ste=) at > Python/symtable.c:396 > 396 PyObject *v = PyDict_GetItemWithError(ste->ste_symbols, name); > (gdb) bt > #0 0x412083fc in _PyST_GetSymbol (name=0xf9a33a60, ste=) at > Python/symtable.c:396 > #1 _PyST_GetScope (ste=, name=0xf9a33a60) at > Python/symtable.c:406 Probably, ste is NULL or in page 0, and it's symtable.c that's miscompiled. There's not a lot of testing of gcc-14 on hppa yet.
[Bug tree-optimization/106511] [13/14 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511 --- Comment #7 from Andrew Macleod --- (In reply to Richard Biener from comment #2) > VRP could use max_stmt_executions here (note it doesn't properly handle loop > nests so the name is somewhat misleading) Given some arbitrary statement S, how do I find the relevant loop pointer to pass to max_stmt_executions?I don't suppose there is a generic version which will take care of that lookup? This seems like something the phi analyzer could easily use to calculate the number of times the modifier statement triggers when we have loop PHIs and some other PHI in parallel.. if I can easily ask how many times stmt S is executed...
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #32 from JuzheZhong --- 26% time reduction seems not enough. Maybe we still need to optimize MD patterns to fix this issue ? But I have no idea to optimize it since I already tried my best to reduce them. According to RVV intrinsic doc: https://github.com/riscv-non-isa/rvv-intrinsic-doc we have these 6 types variant intrinsics: __vop __vop_tu __vop_mu __vop_tum __vop_tumu __vop_m I have fused them into same pattern (which makes the pattern so complicated) to avoid explosion of MD patterns (otherwise, it will explode 6 times if we dedicate each type intrinsic one MD pattern). But seems it's still an issue. And I have no idea how to reduce them.
