aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2023-04-04Fortran: reject module variable as character length in PARAMETER [PR104349]Harald Anlauf3-2/+10
gcc/fortran/ChangeLog: PR fortran/104349 * expr.cc (check_restricted): Adjust check for valid variables in restricted expressions: make no exception for module variables. gcc/testsuite/ChangeLog: PR fortran/104349 * gfortran.dg/der_charlen_1.f90: Adjust dg-patterns. * gfortran.dg/pr104349.f90: New test.
2023-04-04range-op-float: Fix reverse ops of comparisons [PR109386]Jakub Jelinek2-16/+37
I've missed one of my recent range-op-float.cc changes (likely the r13-6967 one) caused FAIL: libphobos.phobos/std/math/algebraic.d execution test FAIL: libphobos.phobos_shared/std/math/algebraic.d execution test regressions, distilled into a C testcase below. In the testcase, we have !(u >= v) condition where both u and v are results of fabs*, which guards t1 = u u<= __FLT_MAX__; and t2 = v u<= __FLT_MAX__; comparisons. From false u >= v where u and v have [0.0, +Inf] NAN ranges we (incorrectly deduce that one of them is [nextafterf (0.0, 1.0), +Inf] NAN and the other is [0.0, nextafterf (+Inf, 0.0)] NAN and from that deduce that one of the comparisons is always true, because UNLE_EXPR with the maximum representable number are false only if the value is +Inf and our ranges tell that is not possible. The bug is that the u >= v comparison determines a sensible range only when it is true - we then know neither operand can be NAN and it behaves correctly. But when the comparison is false, our current code gives sensible answers only if the other op can't be NAN. If it can be NAN, whenever it is NAN, the comparison is always false regardless of the other value, so the other value needs to be VARYING. Now, foperator_unordered_lt::op1_range etc. had code to deal with that for op?.known_nan (), but as the testcase shows, it is enough if it may be a NAN at runtime to make it VARYING. So, the following patch replaces for all those BRS_FALSE cases of the normal non-equality comparisons if (opOTHER.known_isnan ()) r.set_varying (type); to do it also if maybe_isnan (). For the unordered or ... comparisons, it is similar for BRS_TRUE. Those comparisons are true whenever either operand is NAN, or if neither is NAN, the corresponding normal comparison. So, if those comparisons are true and other operand might be a NAN, we can't tell (VARYING), if it is false, currently handling is correct. 2023-04-04 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/109386 * range-op-float.cc (foperator_lt::op1_range, foperator_lt::op2_range, foperator_le::op1_range, foperator_le::op2_range, foperator_gt::op1_range, foperator_gt::op2_range, foperator_ge::op1_range, foperator_ge::op2_range): Make r varying for BRS_FALSE case even if the other op is maybe_isnan, not just known_isnan. (foperator_unordered_lt::op1_range, foperator_unordered_lt::op2_range, foperator_unordered_le::op1_range, foperator_unordered_le::op2_range, foperator_unordered_gt::op1_range, foperator_unordered_gt::op2_range, foperator_unordered_ge::op1_range, foperator_unordered_ge::op2_range): Make r varying for BRS_TRUE case even if the other op is maybe_isnan, not just known_isnan. * gcc.c-torture/execute/ieee/pr109386.c: New test.
2023-04-04sanitizer: missing signed integer overflow errors [PR109107]Marek Polacek6-4/+101
Here we're failing to detect a signed overflow with -O because match.pd, since r8-1516, transforms c = (a + 1) - (int) (short int) b; into c = (int) ((unsigned int) a + 4294946117); wrongly eliding the overflow. This kind of problems is usually avoided by using TYPE_OVERFLOW_SANITIZED in the appropriate place. The first match.pd hunk in the patch fixes it. I've constructed a testcase for each of the surrounding cases as well. Then I noticed that fold_binary_loc/associate has the same problem, so I've added a TYPE_OVERFLOW_SANITIZED there as well (it may be too coarse, sorry). Then I found yet another problem, but instead of fixing it now I've opened 109134. I could probably go on and find a dozen more. PR sanitizer/109107 gcc/ChangeLog: * fold-const.cc (fold_binary_loc): Use TYPE_OVERFLOW_SANITIZED when associating. * match.pd: Use TYPE_OVERFLOW_SANITIZED. gcc/testsuite/ChangeLog: * c-c++-common/ubsan/pr109107-1.c: New test. * c-c++-common/ubsan/pr109107-2.c: New test. * c-c++-common/ubsan/pr109107-3.c: New test. * c-c++-common/ubsan/pr109107-4.c: New test.
2023-04-04arm: Fix vcreate definitionStam Markianos-Wright11-32/+32
From the initial merge of the MVE backend, the vcreate intrinsic has had the vector lanes mixed up, compared to the intended (as per the ACLE) definition. This is also a discrepancy with clang: https://godbolt.org/z/4n93e5aqj This patches simply switches the operands around and makes the tests more specific on the input registers (I do not touch the output Q regs as they vary based on softfp/hardfp or the input registers when the input is a constant, since, in that case, a single register is loaded with a constant and then the same register is used twice as "vmov q0[2], q0[0], r2, r2" and the reg num might not always be guaranteed). gcc/ChangeLog: * config/arm/mve.md (mve_vcvtq_n_to_f_<supf><mode>): Swap operands. (mve_vcreateq_f<mode>): Swap operands. gcc/testsuite/ChangeLog: * gcc.target/arm/mve/intrinsics/vcreateq_f16.c: Tighten test. * gcc.target/arm/mve/intrinsics/vcreateq_f32.c: Tighten test. * gcc.target/arm/mve/intrinsics/vcreateq_s16.c: Tighten test. * gcc.target/arm/mve/intrinsics/vcreateq_s32.c: Tighten test. * gcc.target/arm/mve/intrinsics/vcreateq_s64.c: Tighten test. * gcc.target/arm/mve/intrinsics/vcreateq_s8.c: Tighten test. * gcc.target/arm/mve/intrinsics/vcreateq_u16.c: Tighten test. * gcc.target/arm/mve/intrinsics/vcreateq_u32.c: Tighten test. * gcc.target/arm/mve/intrinsics/vcreateq_u64.c: Tighten test. * gcc.target/arm/mve/intrinsics/vcreateq_u8.c: Tighten test.
2023-04-04amdgcn: Add 64-bit vector notAndrew Stubbs1-0/+17
gcc/ChangeLog: * config/gcn/gcn-valu.md (one_cmpl<mode>2<exec>): New.
2023-04-04riscv: Fix bootstrap [PR109384]Jakub Jelinek2-5/+4
The following patch unbreaks riscv bootstrap, where it previously failed on -Werror=format-diag warning promoted to error. Ok for trunk? Or shall it say e.g. "%<-march=%s%>: %<zfinx%> extension conflicts with %<f>" ? Or say if the current condition is true, do const char *ext = "zfinx"; if (subset_list->lookup ("zdinx")) ext = "zdinx"; else if (subset_list->lookup ("zhinx")) ext = "zhinx"; else if (subset_list->lookup ("zhinxmin")) ext = "zhinxmin"; and "%<-march=%s%>: %qs extension conflicts with %<f>", arch, ext ? Or do similar check for which extension to print against it, const char *ext = "zfinx"; const char *ext2 = "f"; if (subset_list->lookup ("zdinx")) { ext = "zdinx"; if (subset_list->lookup ("d")) ext2 = "d"; } else if (subset_list->lookup ("zhinx")) { ext = "zhinx"; if (subset_list->lookup ("zfh")) ext2 = "zfh"; } else if (subset_list->lookup ("zhinxmin")) { ext = "zhinxmin"; if (subset_list->lookup ("zfhmin")) ext2 = "zfhmin"; } "%<-march=%s%>: %qs extension conflicts with %qs", arch, ext, ext2 ? 2023-04-04 Jakub Jelinek <jakub@redhat.com> PR target/109384 * common/config/riscv/riscv-common.cc (riscv_subset_list::parse): Reword diagnostics about zfinx conflict with f, formatting fixes. * gcc.target/riscv/arch-19.c: Expect a different message about zfinx vs. f conflict.
2023-04-04config: -pthread shouldn't link with -lpthread on SolarisRainer Orth1-1/+0
libpthread has been folded into libc since Solaris 10 and replaced by a filter on libc. Linking with libpthread thus only creates unnecessary runtime overhead. This patch thus removes linking with -lpthread if -pthread/-pthreads is specified, thus getting rid of the libpthread dependency in libatomic, libgdruntime, libgomp, libgphobos, and libitm. Bootstrapped without regressions on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (both Solaris 11.3 and 11.4). 2023-04-03 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> gcc: * config/sol2.h (LIB_SPEC): Don't link with -lpthread.
2023-04-04tree-optimization/109304 - properly handle instrumented aliasesRichard Biener2-3/+18
When adjusting calls to reflect instrumentation we failed to handle calls to aliases since they appear to have no body. Instead resort to symtab node availability. The patch also avoids touching internal function calls in a more obvious way (builtins might have a body available). profiledbootstrap & regtest running on x86_64-unknown-linux-gnu. Honza - does this look OK? PR tree-optimization/109304 * tree-profile.cc (tree_profiling): Use symtab node availability to decide whether to skip adjusting calls. Do not adjust calls to internal functions. * gcc.dg/pr109304.c: New testcase.
2023-04-04rs6000: Fix vector_set_var_p9 by considering BE [PR108807]Kewen Lin1-21/+31
As PR108807 exposes, the current handling in function rs6000_expand_vector_set_var_p9 doesn't take care of big endianness. Currently the function is to rotate the target vector by moving element to-be-set to element 0, set element 0 with the given val, then rotate back. To get the permutation control vector for the rotation, it makes use of lvsr and lvsl, but the element ordering is different for BE and LE (like element 0 is the most significant one on BE while the least significant one on LE), this patch is to add consideration for BE and make sure permutation control vectors for rotations are expected. As tested, it helped to fix the below failures: FAIL: gcc.target/powerpc/pr79251-run.p9.c execution test FAIL: gcc.target/powerpc/pr89765-mc.c execution test FAIL: gcc.target/powerpc/vsx-builtin-10d.c execution test FAIL: gcc.target/powerpc/vsx-builtin-11d.c execution test FAIL: gcc.target/powerpc/vsx-builtin-14d.c execution test FAIL: gcc.target/powerpc/vsx-builtin-16d.c execution test FAIL: gcc.target/powerpc/vsx-builtin-18d.c execution test FAIL: gcc.target/powerpc/vsx-builtin-9d.c execution test PR target/108807 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_expand_vector_set_var_p9): Fix gen function for permutation control vector by considering big endianness.
2023-04-04rs6000: Fix vector parity support [PR108699]Kewen Lin5-7/+61
The failures on the original failed case builtin-bitops-1.c and the associated test case pr108699.c here show that the current support of parity vector mode is wrong on Power. The hardware insns vprtyb[wdq] which operate on the least significant bit of each byte per element, they doesn't match what RTL opcode parity needs, but the current implementation expands it with them wrongly. This patch is to fix the handling with one more insn vpopcntb. PR target/108699 gcc/ChangeLog: * config/rs6000/altivec.md (*p9v_parity<mode>2): Rename to ... (rs6000_vprtyb<mode>2): ... this. * config/rs6000/rs6000-builtins.def (VPRTYBD): Replace parityv2di2 with rs6000_vprtybv2di2. (VPRTYBW): Replace parityv4si2 with rs6000_vprtybv4si2. (VPRTYBQ): Replace parityv1ti2 with rs6000_vprtybv1ti2. * config/rs6000/vector.md (parity<mode>2 with VEC_IP): Expand with popcountv16qi2 and the corresponding rs6000_vprtyb<mode>2. gcc/testsuite/ChangeLog: * gcc.target/powerpc/p9-vparity.c: Add scan-assembler-not for vpopcntb to distinguish parity byte from parity. * gcc.target/powerpc/pr108699.c: New test.
2023-04-03c++: friend template matching [PR107484]Jason Merrill2-0/+14
Here friend matching tries to find a matching non-template friend and fails, so we mark the friend as a template specialization to be determined later. Then cplus_decl_attributes tries again to find a matching function and gets confused by DECL_TEMPLATE_INSTANTIATION without DECL_TEMPLATE_INFO. But it doesn't make sense for find_last_decl to be trying to match anything with DECL_USE_TEMPLATE set; those are matched elsewhere. PR c++/107484 gcc/cp/ChangeLog: * decl2.cc (find_last_decl): Return early if DECL_USE_TEMPLATE. gcc/testsuite/ChangeLog: * g++.dg/lookup/friend25.C: New test.
2023-04-04doc: md.texi (Insn Splitting): Tweak wording for readability.Hans-Peter Nilsson1-15/+15
I needed to check what was allowed in a define_split, but had problems understanding what was meant by "Splitting of jump instruction into sequence that over by another jump instruction". * doc/md.texi (Insn Splitting): Tweak wording for readability. Co-Authored-By: Sandra Loosemore <sandra@codesourcery.com>
2023-04-04Daily bump.GCC Administrator6-1/+71
2023-04-03c++: ICE with loopy var tmpl auto deduction [PR109300]Patrick Palka2-1/+19
Now that we resolve non-dependent variable template-ids ahead of time, cp_finish_decl needs to handle a new invalid situation: we can end up trying to instantiate a variable template with deduced type before we fully parsed its initializer. PR c++/109300 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Diagnose ordinary auto deduction with no initializer, instead of asserting. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ79.C: New test.
2023-04-03Update gcc sv.poJoseph Myers1-372/+250
* sv.po: Update.
2023-04-03PR modula2/109388 clang warnings related to Modula-2Gaius Mulley2-157/+11
This patch removes an unused parameter 'module' from DoVariableDeclaration in M2GCCDeclare.mod. It also removes unused procedures from PHBuild.bnf. gcc/m2/ChangeLog: PR modula2/109388 * gm2-compiler/M2GCCDeclare.mod (DoVariableDeclaration): Remove second parameter module. Adjust all callers to remove the second parameter. * gm2-compiler/PHBuild.bnf (CheckAndInsert): Remove. (InStopSet): Remove. (PeepToken): Remove. (PushQualident): Remove. (SimpleDes): Remove. (ActualParameters): Remove. Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
2023-04-03ipa: Avoid constructing aggregate jump functions with huge offsets (PR 109303)Martin Jambor2-1/+30
We are in the process of changing data structures holding information about constants passed by reference and in aggregates to use unsigned int offsets rather than HOST_WIDE_INT (which was selected simply because that is what fell out of get_ref_base_and_extent at that time) in order to conserve memory, especially at WPA time. PR 109303 testcase discovers that we do not properly check that we only create jump functions with offsets (plus sizes) that fit into the smaller type. This patch adds the necessary check. gcc/ChangeLog: 2023-03-30 Martin Jambor <mjambor@suse.cz> PR ipa/109303 * ipa-prop.cc (determine_known_aggregate_parts): Check that the offset + size will be representable in unsigned int. gcc/testsuite/ChangeLog: 2023-03-30 Jakub Jelinek <jakub@redhat.com> Martin Jambor <mjambor@suse.cz> PR ipa/109303 * gcc.dg/pr109303.c: New test.
2023-04-03build: Check that -lzstd can be linkedRainer Orth2-49/+51
Recent Solaris 11.4 SRUs bundle zstd, but only the 64-bit libraries (no idea why). Because of this, in 32-bit builds cc1 etc. fail to link with undefined references to various ZSTD_* functions from lto-compress.o. This happens because currently only the presence of <zstd.h> is necessary to enable zstd support in lto-compress.cc etc. This patch checks for libzstd first and disables zstd support if missing. Tested on sparc-sun-solaris2.11 with the system installation of zstd (64-bit only) and a locally-compiled one (specified with --with-zstd). 2023-03-28 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> gcc: * configure.ac (ZSTD_LIB): Move before zstd.h check. Unset gcc_cv_header_zstd_h without libzstd. * configure: Regenerate.
2023-04-03param: document ranger-recompute-depthMartin Liska1-0/+4
gcc/ChangeLog: * doc/invoke.texi: Document new param.
2023-04-02Added item entry in docs for the new check_effective_target.Cupertino Miranda1-0/+3
gcc/ * doc/sourcebuild.texi (const_volatile_readonly_section): Document new check_effective_target function.
2023-04-02RISC-V: Fix typoLi Xu1-2/+2
gcc/ChangeLog: * config/riscv/riscv-vector-builtins.def (vuint32m8_t): Fix typo. (vfloat32m8_t): Likewise
2023-04-03rs6000: Modify test case after mode promotion disabledHaochen Gui1-2/+1
gcc/testsuite/ PR target/102146 * gcc.target/powerpc/pr56605.c: Modify the match pattern for dump scan.
2023-04-03Document signbitm2.liuhongt1-0/+11
gcc/ChangeLog: * doc/md.texi: Document signbitm2.
2023-04-03Daily bump.GCC Administrator4-1/+54
2023-04-02Fix gnat.dg/opt39.adb on hppa.John David Anglin1-1/+1
Add hppa*-*-* to dg-additional-options list. 2023-04-02 John David Anglin <danglin@gcc.gnu.org> gcc/testsuite/ChangeLog: PR target/109375 * gnat.dg/opt39.adb: Add hppa*-*-* to dg-additional-options list.
2023-04-02Skip gnat.dg/prot7.adb on hppa.John David Anglin1-0/+1
Test needs to be skipped if the target does not support atomic primitives. 2023-04-02 John David Anglin <danglin@gcc.gnu.org> gcc/testsuite/ChangeLog: PR target/109376 * gnat.dg/prot7.adb: Skip on hppa.
2023-04-02PR modula2/109336 pass -fmod= though and build m2/stage2/cc1gm2 libsGaius Mulley5-14/+45
This patch enables gm2 to pass -fmod= though to cc1gm2. It also builds the libraries for m2/stage2/cc1gm2 with no named path and full debugging. gcc/m2/ChangeLog: PR modula2/109336 * Make-lang.in (GM2_O): Set to -O0. (GM2_LIBS): Remove target libraries and replace with build libs. (BUILD-LIBS): New declaration. (m2/gm2-libs/libgm2.a): New rule. (m2/gm2-libs/%.o): New rule. (m2/gm2-libs/choosetemp.o): New rule. * gm2-compiler/M2ColorString.mod (append): Use ADR rather than implicit conversion. * gm2-compiler/M2Comp.mod (Compile): Add qprintf messages for when a source file is not found. Improve comments and formatting. * gm2-libs-ch/cgetopt.c (cgetopt_cgetopt_long): Remove ansi-decl.h. Add getopt.h. (cgetopt_cgetopt_long_only): Change cgetopt_ to getopt_. * gm2spec.cc (lang_specific_driver): Do not skip -fmod=. Remove comment. Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
2023-04-02RISC-V: Fix reload fail issue on vector mac instructionsJuzhe-Zhong5-185/+789
Vector mac instructions has LRA issue during high register pressure, It will failed to reload when picked first alternative, because it will require reload 2 input operands into same register as input operand, so we adding an extra operand to generate one more move pattern to relax such restricted constraint. This path fix ICE of ternary intrinsic: bug.C:144:2: error: unable to find a register to spill 144 | } | ^ bug.C:144:2: error: this is the insn: (insn 462 972 919 24 (set (reg/v:VNx8DI 546 [orig:192 var_10 ] [192]) (if_then_else:VNx8DI (unspec:VNx8BI [ (reg/v:VNx8BI 603 [orig:179 var_13 ] [179]) (const_int 13 [0xd]) (const_int 2 [0x2]) (const_int 0 [0]) repeated x2 (reg:SI 66 vl) (reg:SI 67 vtype) ] UNSPEC_VPREDICATE) (plus:VNx8DI (mult:VNx8DI (reg/v:VNx8DI 605 [orig:190 var_6 ] [190]) (reg/v:VNx8DI 547 [orig:160 var_51 ] [160])) (reg/v:VNx8DI 548 [orig:161 var_52 ] [161])) (reg/v:VNx8DI 605 [orig:190 var_6 ] [190]))) "bug.C":131:48 4171 {*pred_maddvnx8di} (expr_list:REG_DEAD (reg/v:VNx8DI 605 [orig:190 var_6 ] [190]) (expr_list:REG_DEAD (reg/v:VNx8BI 603 [orig:179 var_13 ] [179]) (expr_list:REG_DEAD (reg/v:VNx8DI 547 [orig:160 var_51 ] [160]) (expr_list:REG_DEAD (reg/v:VNx8DI 548 [orig:161 var_52 ] [161]) (nil)))))) gcc/ChangeLog: * config/riscv/vector.md: Fix RA constraint. gcc/testsuite/ChangeLog: * g++.target/riscv/rvv/base/bug-19.C: New test. * g++.target/riscv/rvv/base/bug-20.C: New test. * g++.target/riscv/rvv/base/bug-21.C: New test. * g++.target/riscv/rvv/base/bug-22.C: New test. Signed-off-by: Ju-Zhe Zhong <juzhe.zhong@rivai.ai> Co-authored-by: kito-cheng <kito.cheng@sifive.com>
2023-04-02RISC-V: Fix ICE and codegen error of scalar move in RV32 system.Juzhe-Zhong5-14/+52
We need to reset the AVL to 0 or 1 for scalar move for RV32 system, For any non-zero AVL input, we set that to 1, and zero will keep as zero. We are using wrong way (by andi with 1) before to achieve that, and it will cause ICE with const_int, and also wrong behavior, so now we have two code path, one for const_int and one for non-const_int. bug.C:144:2: error: unrecognizable insn: 144 | } | ^ (insn 684 683 685 26 (set (reg:SI 513) (and:SI (const_int 4 [0x4]) (const_int 1 [0x1]))) "bug.C":115:47 -1 (nil)) andi a4,a4,1 ===> sgtu a4,a4,zero vsetlvi tu vsetvli tu vlse vlse gcc/ChangeLog: * config/riscv/riscv-protos.h (gen_avl_for_scalar_move): New function. * config/riscv/riscv-v.cc (gen_avl_for_scalar_move): New function. * config/riscv/vector.md: Fix scalar move bug. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/scalar_move-6.c: Adapt test. * gcc.target/riscv/rvv/base/scalar_move-9.c: New test.
2023-04-02Daily bump.GCC Administrator5-1/+107
2023-04-01c++: NTTP constraint depending on outer parms [PR109160]Patrick Palka3-11/+53
Here we're crashing during satisfaction for the NTTP 'C<B> auto V' ultimately because convert_template_argument / unify don't pass all outer template arguments to do_auto_deduction, and during satisfaction we need to know all arguments. While these callers do pass some outer arguments, they are only sufficient to properly substitute the (level-lowered) 'auto' and are not necessarily the entire set. Fortunately it seems these callers have access to the full set of outer arguments via convert_template_argument's 'in_decl' parameter and unify's 'tparms' parameter. So this patch adds a new parameter to do_auto_deduction, used only during adc_unify deduction, through which these callers can pass the enclosing (partially instantiated) template and from which do_auto_deduction can obtain _all_ outer template arguments for sake of satisfaction. This patch also ensures that the 'in_decl' argument passed to coerce_template_parms is always a TEMPLATE_DECL, which in turn allows us to pass it as-is to do_auto_deduction; the only coerce_template_parms caller that needed adjustment was tsubst_decl it seems. PR c++/109160 gcc/cp/ChangeLog: * cp-tree.h (do_auto_deduction): Add defaulted tmpl parameter. * pt.cc (convert_template_argument): Pass 'in_decl' as 'tmpl' to do_auto_deduction. (tsubst_decl) <case VAR_/TYPE_DECL>: Pass 'tmpl' instead of 't' as 'in_decl' to coerce_template_parms. (unify) <case TEMPLATE_PARM_INDEX>: Pass TPARMS_PRIMARY_TEMPLATE as 'tmpl' to do_auto_deduction. (do_auto_deduction): Document default arguments. Rename local variable 'tmpl' to 'ctmpl'. Use 'tmpl' to obtain a full set of template arguments for satisfaction in the adc_unify case. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-placeholder12.C: New test.
2023-04-01c++: improve "NTTP argument considered unused" fix [PR53164, PR105848]Patrick Palka4-18/+139
r13-995-g733a792a2b2e16 worked around the problem of (pointer to) function NTTP arguments not always getting marked as odr-used, by redundantly calling mark_used on the substituted ADDR_EXPR callee of a CALL_EXPR. That is just a narrow workaround however, since it assumes the function is later called, but the use as a template argument alone should constitute an odr-use of the function (since template arguments are an evaluated context, and we're really passing its address); we shouldn't need to subsequently call or otherwise use the function NTTP argument. This patch fixes this in a more general way by walking the template arguments of each specialization that's about to be instantiated and redundantly calling mark_used on all entities used within. As before, the call to mark_used as it worst a no-op, but it compensates for the situation where the specialization was first formed in a template context in which mark_used is inhibited. Another approach would be to call mark_used whenever we substitute a TEMPLATE_PARM_INDEX, but that would result in many more redundant calls to mark_used compared to this approach. And as the second testcase below illustrates, we also need to walk C++20 class NTTP arguments which can be large and thus expensive to walk repeatedly. The change to invalid_tparm_referent_p is needed to avoid incorrectly rejecting class NTTP arguments containing function pointers as in the testcase. (The third testcase is unrelated to this fix, but it helped rule out an earlier approach I was considering and it seems we don't have existing test coverage for this situation.) PR c++/53164 PR c++/105848 gcc/cp/ChangeLog: * pt.cc (invalid_tparm_referent_p): Accept ADDR_EXPR of FUNCTION_DECL. (instantiate_class_template): Call mark_template_arguments_used. (tsubst_copy_and_build) <case CALL_EXPR>: Revert r13-995 change. (mark_template_arguments_used): Define. (instantiate_body): Call mark_template_arguments_used. gcc/testsuite/ChangeLog: * g++.dg/template/fn-ptr3a.C: New test. * g++.dg/template/fn-ptr3b.C: New test. * g++.dg/template/fn-ptr4.C: New test.
2023-04-01Change "long_double" into "long double" for C prototypes from Fortran.Thomas Koenig1-0/+2
gcc/fortran/ChangeLog: * dump-parse-tree.cc (get_c_type_name): Fix "long_long" type name to be "long long".
2023-04-01range-op-float: Further foperator_{,not_}equal::fold_range fixJakub Jelinek1-0/+14
On Fri, Mar 31, 2023 at 12:45:10PM +0200, Jakub Jelinek via Gcc-patches wrote: > - there is a missing case (not handled in this patch) where both operands > are known to be zeros, but not singleton zeros This patch adds those cases. 2023-04-01 Jakub Jelinek <jakub@redhat.com> * range-op-float.cc (foperator_equal::fold_range): If at least one of the op ranges is not singleton and neither is NaN and all 4 bounds are zero, return [1, 1]. (foperator_not_equal::fold_range): In the same case return [0, 0].
2023-04-01range-op-float: Further comparison fixesJakub Jelinek5-46/+112
On Fri, Mar 31, 2023 at 09:57:54AM +0200, Jakub Jelinek via Gcc-patches wrote: > and so if maybe_isnan, they always return [0, 1]. Now, thinking about it, > this is unnecessary pessimization, for the case where the ... block > returns range_false (type) we actually could do it also if maybe_isnan (op1, > op2), because if one or both operands are NAN, the comparison will be false, > and if neither is NAN, the comparison will be also false. Will fix > incrementally today. Here it is. 1) the foperator_{,not_}equal::fold_range cases - we have correctly first a case handling known_isnan on either operand, return there range_false (type) - EQ, resp. range_true (type) - NE - next we handle the singleton cases, maybe_isnan + singleton isn't singleton, so these are ok - there is a missing case (not handled in this patch) where both operands are known to be zeros, but not singleton zeros - there is some !maybe_isnan (op1, op2) handling which tries to prove when the operands are certainly not equal and results in range_false (type) - EQ, resp. range_true (type) - NE - otherwise range_true_and_false (type) Now, I think (and this patch implements it) that the !maybe_isnan (op1, op2) check is unnecessary. If we prove that when ignoring maybe NANs, the ranges don't intersect and so the comparison is always false for EQ or always true for NE, if NANs can appear, it doesn't change anything on that either, for EQ if NAN appears, the result is false like what we proved for the finite ranges, for NE if NAN appears, the result is true like what we proved for the finite ranges 2) foperator_{lt,le,gt,ge}::fold_range cases - these have correctly known_isnan on either operand first and return there range_false (type) - then !maybe_isnan (op1, op2) condition guarded checks - finally range_true_and_false (type) - so do that for maybe_isnan (op1, op2) Here in the !maybe_isnan (op1, op2) guarded code we have some condition which results in range_true (type), another condition which results in range_false (type) and otherwise range_true_and_false (type). Now, the condition which results in range_false (type) can be IMHO done also for the maybe_isnan (op1, op2) cases, because it is [0, 0] if both operands are finite or [0, 0] if either operand is NAN. 3) finally, LTGT_EXPR wasn't handled at all. LTGT_EXPR is the inverse comparision to UNEQ_EXPR, I believe both raise exceptions only if either operand is sNaN, UNEQ_EXPR is true if both operands are either equal or either of the operands is NAN, while LTGT_EXPR is true if the operands compare either smaller or larger and is false if either of the operands is NAN. 2023-04-01 Jakub Jelinek <jakub@redhat.com> * range-op-float.cc (foperator_equal::fold_range): Perform the non-singleton handling regardless of maybe_isnan (op1, op2). (foperator_not_equal::fold_range): Likewise. (foperator_lt::fold_range, foperator_le::fold_range, foperator_gt::fold_range, foperator_ge::fold_range): Perform the real_* comparison check which results in range_false (type) even if maybe_isnan (op1, op2). Simplify. (foperator_ltgt): New class. (fop_ltgt): New variable. (floating_op_table::floating_op_table): Handle LTGT_EXPR using fop_ltgt. * gcc.dg/torture/inf-compare-1.c: Add dg-additional-options -fno-tree-dominator-opts -fno-tree-vrp. * gcc.dg/torture/inf-compare-1-float.c: Likewise. * gcc.dg/torture/inf-compare-2.c: Likewise. * gcc.dg/torture/inf-compare-2-float.c: Likewise.
2023-04-01testsuite: Add testcase for already fixed PR [PR109362]Jakub Jelinek1-0/+19
This PR got fixed with r13-137. Add a testcase to make sure it doesn't reappear. 2023-04-01 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/109362 * gcc.target/i386/pr109362.c: New test.
2023-04-01aarch64, builtins: Include PR registers in FUNCTION_ARG_REGNO_P etc. [PR109254]Jakub Jelinek5-22/+65
The following testcase is miscompiled on aarch64-linux in the regname pass, because while the function takes arguments in the p0 register, FUNCTION_ARG_REGNO_P doesn't reflect that, so DF doesn't know the register is used in register passing. It sees 2 chains with p1 register and wants to replace the second one and as DF doesn't know p0 is live at the start of the function, it will happily use p0 register even when it is used in subsequent instructions. The following patch fixes that. FUNCTION_ARG_REGNO_P returns non-zero for p0-p3 (unconditionally, seems for the floating/vector registers it doesn't conditionalize them on TARGET_FLOAT either, but if you want, I can conditionalize p0-p3 on TARGET_SVE), similarly targetm.calls.function_value_regno_p returns true for p0-p3 registers if TARGET_SVE (again for consistency, that function conditionalizes the float/vector on TARGET_FLOAT). Now, that change broke bootstrap in libobjc and some __builtin_apply_args/__builtin_apply/__builtin_return tests. The aarch64_get_reg_raw_mode hook already documents that SVE scalable arg/return passing is fundamentally incompatible with those builtins, but unlike the floating/vector regs where it forces a fixed vector mode, I think there is no fixed mode which could be used for p0-p3. So, I have tweaked the generic code so that it uses VOIDmode return from that hook to signal that a register shouldn't be touched by __builtin_apply_args/__builtin_apply/__builtin_return despite being mentioned in FUNCTION_ARG_REGNO_P or targetm.calls.function_value_regno_p. gcc/ 2023-04-01 Jakub Jelinek <jakub@redhat.com> PR target/109254 * builtins.cc (apply_args_size): If targetm.calls.get_raw_arg_mode returns VOIDmode, handle it like if the register isn't used for passing arguments at all. (apply_result_size): If targetm.calls.get_raw_result_mode returns VOIDmode, handle it like if the register isn't used for returning results at all. * target.def (get_raw_result_mode, get_raw_arg_mode): Document what it means to return VOIDmode. * doc/tm.texi: Regenerated. * config/aarch64/aarch64.cc (aarch64_function_value_regno_p): Return TARGET_SVE for P0_REGNUM. (aarch64_function_arg_regno_p): Also return true for p0-p3. (aarch64_get_reg_raw_mode): Return VOIDmode for PR_REGNUM_P regs. gcc/testsuite/ 2023-04-01 Jakub Jelinek <jakub@redhat.com> Richard Sandiford <richard.sandiford@arm.com> PR target/109254 * gcc.target/aarch64/sve/pr109254.c: New test.
2023-04-01c++,coroutines: Stabilize names of promoted slot vars [PR101118].Iain Sandoe1-1/+1
When we need to 'promote' a value (i.e. store it in the coroutine frame) it is given a frame entry name. This was based on the DECL_UID for slot vars. However, when LTO is used, the names from multiple TUs become visible at the same time, and the DECL_UIDs usually differ between units. This leads to a "ODR mismatch" warning for the frame type. The fix here is to use the current promoted temporaries count to produce the name, this is stable between TUs and computed per coroutine. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> PR c++/101118 gcc/cp/ChangeLog: * coroutines.cc (flatten_await_stmt): Use the current count of promoted temporaries to build a unique name for the frame entries.
2023-04-01Daily bump.GCC Administrator3-1/+108
2023-03-31testsuite, analyzer: Fix up pipe-glibc.c testcase [PR107396]Jakub Jelinek1-0/+4
The gcc.dg/analyzer/pipe-glibc.c test FAILs when using recent glibc headers and succeeds with older headers. The important change is that https://sourceware.org/git/?p=glibc.git;a=commit;h=c1760eaf3b575ad174fd88b252fd16bd525fa818 in 2021 added __attribute__ ((__malloc__ (fclose, 1))) attribute to fdopen, so in write_to_pipe there is an excess warning: .../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c: In function 'write_to_pipe': .../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:28:3: warning: use of possibly-NULL 'stream' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument] .../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:27:12: note: (1) this call could return NULL .../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:28:3: note: (2) argument 4 ('stream') from (1) could be NULL where non-null expected <built-in>: note: argument 4 of '__builtin_fwrite' must be non-null Strangely, nothing is reported on the read_from_pipe function, seems fwrite/fprintf/fputc etc. are builtins in GCC and we mark the FILE * arguments as nonnull there on the builtin declarations, while fgetc/fread etc. aren't builtins and glibc doesn't mark any of those using nonnull. Shall we change that on the glibc side? Anyway, because this differs based on glibc version and I think the above warning is not the primary intention of the test, I think it is best to tweak it so that this warning isn't reported. Another option would be avoid using glibc headers and use our own declarations, or make sure we add the malloc with fclose attribute ourselves (but fdopen in the libc headers could be a macro, so not sure __typeof (fdopen) fdopen __attribute__ ((__malloc__, __malloc__ (fclose, 1))); would work). Or use -Wno-analyzer-possible-null-arguments in dg-additional-options? 2023-03-31 Jakub Jelinek <jakub@redhat.com> PR analyzer/107396 * gcc.dg/analyzer/pipe-glibc.c (read_from_pie, write_to_pipe): Exit if fdopen returns NULL.
2023-03-31Adjust testcases to not produce errors..Andrew MacLeod2-2/+3
tree-optimization/109363 gcc/testsuite/ * g++.dg/warn/Wstringop-overflow-4.C: Always check bogus message. * gcc.dg/tree-ssa/pr23109.c: Disable better recomputations.
2023-03-31LRA: Implement commutative operands exchange for combining secondary memory ↵Vladimir N. Makarov2-1/+27
reload and original insn The patch implements trying commutative operands exchange for combining secondary memory reload and original insn. PR rtl-optimization/109052 gcc/ChangeLog: * lra-constraints.cc: (combine_reload_insn): New function. gcc/testsuite/ChangeLog: * gcc.target/i386/pr109052-2.c: New.
2023-03-31range-op-float, value-range: Fix up handling of UN{LT,LE,GT,GE,EQ}_EXPR and ↵Jakub Jelinek6-11/+103
handle comparisons in get_tree_range [PR91645] When looking into PR91645, I've noticed we handle UN{LT,LE,GT,GE,EQ}_EXPR comparisons incorrectly. All those are unordered or ..., we correctly return [1, 1] if one or both operands are known NANs, and correctly ask the non-UN prefixed op to fold_range if neither operand may be NAN. But for the case where one or both operands may be NAN, we always return [0, 1]. The UN* fold_range tries to handle it by asking the non-UN prefixed fold_range and if it returns [1, 1] return that, if it returns [0, 0] or [0, 1] return [0, 1], which makes sense, because the maybe NAN means that it is the non-UN prefixed fold_range unioned with [1, 1] in case the maybe NAN is actually NAN at runtime. The problem is that the non-UN prefixed fold_range always returns [0, 1] because those fold_range implementations are like: if (op1.known_isnan () || op2.known_isnan ()) r = range_false (type); else if (!maybe_isnan (op1, op2)) { ... } else r = range_true_and_false (type); and so if maybe_isnan, they always return [0, 1]. Now, thinking about it, this is unnecessary pessimization, for the case where the ... block returns range_false (type) we actually could do it also if maybe_isnan (op1, op2), because if one or both operands are NAN, the comparison will be false, and if neither is NAN, the comparison will be also false. Will fix incrementally today. Anyway, the following patch fixes it by asking the non-UN prefixed fold_range on ranges with NAN cleared, which I think does the right thing in all cases. Another change in the patch is that range_query::get_tree_range always returned VARYING for comparisons, this patch allows to ask about those as well (they are very much like binary ops, except they take the important type from the types of the operands rather than result). Initially I've developed this patch together with changes to tree-call-cdce.cc, but those result in one regression and apparently aren't actually needed to fix this bug, the range-op-float.cc changes are enough. 2023-03-31 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/91645 * range-op-float.cc (foperator_unordered_lt::fold_range, foperator_unordered_le::fold_range, foperator_unordered_gt::fold_range, foperator_unordered_ge::fold_range, foperator_unordered_equal::fold_range): Call the ordered fold_range on ranges with cleared NaNs. * value-query.cc (range_query::get_tree_range): Handle also COMPARISON_CLASS_P trees. * gcc.target/i386/pr103559-1.c: New test. * gcc.target/i386/pr103559-2.c: New test. * gcc.target/i386/pr103559-3.c: New test. * gcc.target/i386/pr103559-4.c: New test.
2023-03-31RISC-V: Fix missing file dependency in RISC-V back-end [PR109328]Kito Cheng1-13/+30
gcc/ChangeLog: PR target/109328 * config/riscv/t-riscv: Add missing dependencies. Co-authored-by: Andrew Pinski <pinskia@gmail.com>
2023-03-31Adjust memory_move_cost for MASK_REGS when MODE_SIZE > 8.liuhongt1-1/+4
It's impossible to put modes whose size > 8 into MASK_REGS. gcc/ChangeLog: * config/i386/i386.cc (inline_memory_move_cost): Return 100 for MASK_REGS when MODE_SIZE > 8.
2023-03-31c-c++-common/Warray-bounds.c: Fix excess warnings on LLP64Jonathan Yong1-4/+4
Excess errors on x86_64-w64-mingw32: /home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:50:3: warning: array subscript 4611686018427387902 is above array bounds of 'struct S16[]' [-Warray-bounds=] /home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:55:3: warning: array subscript 4611686018427387902 is above array bounds of 'struct S16[]' [-Warray-bounds=] /home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:90:3: warning: array subscript 658812288346769699 is above array bounds of 'struct S16[][7]' [-Warray-bounds=] gcc/testsuite/ChangeLog: * c-c++-common/Warray-bounds.c: Fix excess warnings on LLP64. Signed-off-by: Jonathan Yong <10walls@gmail.com>
2023-03-31Rename ufix_trunc/ufloat* patterns to fixuns_trunc/floatuns* to align with ↵liuhongt4-60/+84
standard pattern name. There's some typo for the standard pattern name for unsigned_{float,fix}, it should be floatunsmn2/fixuns_truncmn2, not ufloatmn2/ufix_truncmn2 in current trunk, the patch fix the typo, also change all though ufix_trunc/ufloat patterns. Also vcvttps2udq is available under AVX512VL, so it can be generated directly instead of being emulated via vcvttps2dq. gcc/ChangeLog: PR target/85048 * config/i386/i386-builtin.def (BDESC): Adjust icode name from ufloat/ufix to floatuns/fixuns. * config/i386/i386-expand.cc (ix86_expand_vector_convert_uns_vsivsf): Adjust comments. * config/i386/sse.md (ufloat<sseintvecmodelower><mode>2<mask_name><round_name>): Renamed to .. (<mask_codefor>floatuns<sseintvecmodelower><mode>2<mask_name><round_name>):.. this. (<mask_codefor><avx512>_ufix_notrunc<sf2simodelower><mode><mask_name><round_name>): Renamed to .. (<mask_codefor><avx512>_fixuns_notrunc<sf2simodelower><mode><mask_name><round_name>): .. this. (<fixsuffix>fix_truncv16sfv16si2<mask_name><round_saeonly_name>): Renamed to .. (fix<fixunssuffix>_truncv16sfv16si2<mask_name><round_saeonly_name>):.. this. (ufloat<si2dfmodelower><mode>2<mask_name>): Renamed to .. (floatuns<si2dfmodelower><mode>2<mask_name>): .. this. (ufloatv2siv2df2<mask_name>): Renamed to .. (<mask_codefor>floatunsv2siv2df2<mask_name>): .. this. (ufix_notrunc<mode><si2dfmodelower>2<mask_name><round_name>): Renamed to .. (fixuns_notrunc<mode><si2dfmodelower>2<mask_name><round_name>): .. this. (ufix_notruncv2dfv2si2): Renamed to .. (fixuns_notruncv2dfv2si2):.. this. (ufix_notruncv2dfv2si2_mask): Renamed to .. (fixuns_notruncv2dfv2si2_mask): .. this. (*ufix_notruncv2dfv2si2_mask_1): Renamed to .. (*fixuns_notruncv2dfv2si2_mask_1): .. this. (ufix_truncv2dfv2si2): Renamed to .. (*fixuns_truncv2dfv2si2): .. this. (ufix_truncv2dfv2si2_mask): Renamed to .. (fixuns_truncv2dfv2si2_mask): .. this. (*ufix_truncv2dfv2si2_mask_1): Renamed to .. (*fixuns_truncv2dfv2si2_mask_1): .. this. (ufix_truncv4dfv4si2<mask_name>): Renamed to .. (fixuns_truncv4dfv4si2<mask_name>): .. this. (ufix_notrunc<mode><sseintvecmodelower>2<mask_name><round_name>): Renamed to .. (fixuns_notrunc<mode><sseintvecmodelower>2<mask_name><round_name>): .. this. (ufix_trunc<mode><sseintvecmodelower>2<mask_name>): Renamed to .. (<mask_codefor>fixuns_trunc<mode><sseintvecmodelower>2<mask_name>): .. this. gcc/testsuite/ChangeLog: * g++.target/i386/pr85048.C: New test.
2023-03-31Daily bump.GCC Administrator5-1/+125
2023-03-30c++: anonymous union member reference [PR105452]Jason Merrill5-3/+44
While parsing the anonymous union, we don't yet know that it's an anonymous union, so we build the reference to 'v' in the static_assert relative to the union type. But at instantiation time we know it's an anonymous union, so we need to avoid trying to check access for 'v' in the union again; the simplest approach seemed to be to make accessible_p step out to the containing class. While looking at this I also noticed that we were having trouble with DMI in an anonymous union referring to members of the containing class; there we just need to give current_class_ptr the right type. PR c++/105452 gcc/cp/ChangeLog: * search.cc (type_context_for_name_lookup): New. (accessible_p): Handle anonymous union. * init.cc (maybe_instantiate_nsdmi_init): Use type_context_for_name_lookup. * parser.cc (cp_parser_class_specifier): Likewise. * cp-tree.h (type_context_for_name_lookup): Declare. gcc/testsuite/ChangeLog: * g++.dg/lookup/anon8.C: New test.
2023-03-30c++: generic lambda and function ptr conv [PR105221]Jason Merrill2-3/+38
We weren't properly considering the function pointer conversions in deduction between FUNCTION_TYPE; we just hardcoded the UNIFY_ALLOW_MORE_CV_QUAL semantics, which are backwards when deducing for a template conversion function like the one in a generic lambda. And when I started checking the ALLOW flags, I needed to make sure they stay set to avoid breaking trailing13.C. PR c++/105221 gcc/cp/ChangeLog: * pt.cc (unify) [FUNCTION_TYPE]: Handle function pointer conversions. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/noexcept-type27.C: New test.
generated by cgit v1.1 at 2025-09-22 19:27:27 +0000