aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2023-05-04tree-optimization/109724 - new testcaseRichard Biener1-0/+32
The following adds a testcase for PR109724 which was caused by backporting r13-2375-gbe1b42de9c151d and fixed by r11-199-g2b42509f8b7bdf. PR tree-optimization/109724 * g++.dg/torture/pr109724.C: New testcase. (cherry picked from commit ee99aaae4aeecd55f1d945a959652cf07e3b2e9e)
2023-05-04i386: Fix up handling of debug insns in STV [PR109676]Jakub Jelinek2-4/+51
The following testcase ICEs because STV replaces there (debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1 (nil)) with (debug_insn 114 47 51 8 (var_location:TI D#3 (reg:V1TI 91 [ p ])) -1 (nil)) which is invalid because of the mode mismatch. STV has fix_debug_reg_uses function which is supposed to fix this up and adjust such debug insns into (debug_insn 114 47 51 8 (var_location:TI D#3 (subreg:TI (reg:V1TI 91 [ p ]) 0)) -1 (nil)) but it doesn't trigger here. The IL before stv1 has: (debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1 (nil)) ... (insn 63 62 64 8 (set (mem/c:TI (reg/f:DI 89 [ .result_ptr ]) [0 <retval>.mStorage+0 S16 A32]) (reg:TI 91 [ p ])) "pr109676.C":4:48 87 {*movti_internal} (expr_list:REG_DEAD (reg:TI 91 [ p ]) (nil))) in bb 8 and (insn 97 96 98 9 (set (reg:TI 91 [ p ]) (mem/c:TI (plus:DI (reg/f:DI 19 frame) (const_int -32 [0xffffffffffffffe0])) [0 p+0 S16 A128])) "pr109676.C":26:12 87 {*movti_internal} (nil)) (insn 98 97 99 9 (set (mem/c:TI (plus:DI (reg/f:DI 19 frame) (const_int -64 [0xffffffffffffffc0])) [0 tmp+0 S16 A128]) (reg:TI 91 [ p ])) "pr109676.C":26:12 87 {*movti_internal} (nil)) in bb9. PUT_MODE on a REG is done in two spots in timode_scalar_chain::convert_insn, one is: switch (GET_CODE (dst)) { case REG: if (GET_MODE (dst) == TImode) { PUT_MODE (dst, V1TImode); fix_debug_reg_uses (dst); } if (GET_MODE (dst) == V1TImode) when seeing the REG in SET_DEST and another one the hunk the patch adjusts. Because bb 8 comes first in the order the pass walks the bbs, we first notice the TImode pseudo on insn 63 where it is SET_SRC, use PUT_MODE there unconditionally, so for a shared REG it changes all other uses in the IL, and then don't call fix_debug_reg_uses because DF_REG_DEF_CHAIN (REGNO (src)) is non-NULL - the REG is set in insn 97 but we haven't processed it yet. Later on we process insn 97, but because the REG in SET_DEST already has V1TImode, we don't do anything, even when the src handling code earlier relied on it being done. The following patch fixes this by using similar code for both dst and src, in particular calling fix_debug_reg_uses once when we actually change REG mode from TImode to V1TImode, and not later on. 2023-05-04 Jakub Jelinek <jakub@redhat.com> PR debug/109676 * config/i386/i386-features.cc (timode_scalar_chain::convert_insn): If src is REG, change its mode to V1TImode and call fix_debug_reg_uses for it only if it still has TImode. Don't decide whether to call fix_debug_reg_uses based on whether SRC is ever set or not. * g++.target/i386/pr109676.C: New test. (cherry picked from commit 3a715d3e136fc4dfdc42cb6a3ee1a7df3e2a171a)
2023-05-04Docs: Add vector register constarint for asm operandsKito Cheng1-0/+9
`vr`, `vm` and `vd` constarint for vector register constarint, those 3 constarint has implemented on LLVM as well. gcc/ChangeLog: * doc/md.texi (RISC-V): Add vr, vm, vd constarint. (cherry picked from commit e8511cbba692a9f3ff4d9c74e902fab03f154bbd)
2023-05-04RISC-V: Fix wrong check of register occurrences [PR109535]Ju-Zhe Zhong3-1/+168
count_occurrences will conly count same RTX (same code and same mode), but what we want to track is the occurrence of a register, a register might appeared in the insn with different mode or contain in SUBREG. Testcase coming from Kito. gcc/ChangeLog: PR target/109535 * config/riscv/riscv-vsetvl.cc (count_regno_occurrences): New function. (pass_vsetvl::cleanup_insns): Fix bug. gcc/testsuite/ChangeLog: PR target/109535 * g++.target/riscv/rvv/base/pr109535.C: New test. * gcc.target/riscv/rvv/base/pr109535.c: New test. Signed-off-by: Ju-Zhe Zhong <juzhe.zhong@rivai.ai> Co-authored-by: kito-cheng <kito.cheng@sifive.com> (cherry picked from commit a2d12abedc89a9439fd6aadc38730fdadca0684f)
2023-05-04Daily bump.GCC Administrator2-1/+21
2023-05-03Revert "c++: reorganize friend template matching [PR91618]"Jason Merrill3-49/+61
This patch was just a cleanup after the actual bugfix, so let's revert it on the branch. PR c++/109649 This reverts commit e9d2adc17d0dbe46db67e1b618dea888d5c7aca3.
2023-05-03c++: Fix up VEC_INIT_EXPR gimplification after r12-7069Jakub Jelinek1-9/+9
During patch backporting, I've noticed that while most cp_walk_tree calls with cp_fold_r callback callers were changed from &pset to cp_fold_data &data, the VEC_INIT_EXPR gimplifications has not, so it still passes just address of a hash_set<tree> and so if during the folding we ever touch data->flags, we use uninitialized data there. The following patch changes it to do the same thing as cp_fold_function because the VEC_INIT_EXPR gimplifications will happen on function bodies only. 2023-05-03 Jakub Jelinek <jakub@redhat.com> * cp-gimplify.cc (cp_fold_data): Move definition earlier. (cp_gimplify_expr): Pass address of ff_genericize | ff_mce_false constructed data rather than &pset to cp_walk_tree with cp_fold_r. (cherry picked from commit 8d193b12d6f07ae0196db8296a49c881c1638c01)
2023-05-03Daily bump.GCC Administrator5-1/+60
2023-05-02Revert "c++: *this folding in constexpr call"Jason Merrill1-6/+5
The earlier commit wasn't fixing a known bug, so let's revert it on the branch. PR c++/109678 This reverts commit 1189c03859cefef4fc4fd44d57eb3d4d3348b562.
2023-05-02c++: array DMI and member fn [PR109666]Jason Merrill5-41/+58
Here it turns out I also needed to adjust cfun when stepping out of the member function to instantiate the DMI. But instead of adding that tweak, let's unify with instantiate_body and just push_to_top_level instead of trying to do the minimum subset of it. There was no measurable change in compile time on stdc++.h. This should also resolve 109506 without yet another tweak. PR c++/109666 gcc/cp/ChangeLog: * name-lookup.cc (maybe_push_to_top_level) (maybe_pop_from_top_level): Split out... * pt.cc (instantiate_body): ...from here. * init.cc (maybe_instantiate_nsdmi_init): Use them. * name-lookup.h: Declare them.. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-array2.C: New test.
2023-05-02c++: fix 'unsigned typedef-name' extension [PR108099]Jason Merrill4-7/+81
In the comments for PR108099 Jakub provided some testcases that demonstrated that even before the regression noted in the patch we were getting the semantics of this extension wrong: in the unsigned case we weren't producing the corresponding standard unsigned type but another distinct one of the same size, and in the signed case we were just dropping it on the floor and not actually returning a signed type at all. The former issue is fixed by using c_common_signed_or_unsigned_type instead of unsigned_type_for, and the latter issue by adding a (signed_p && typedef_decl) case. This patch introduces a failure on std/ranges/iota/max_size_type.cc due to the latter issue, since the testcase expects 'signed rep_t' to do something sensible, and previously we didn't. Now that we do, it exposes a bug in the __max_diff_type::operator>>= handling of sign extension: when we evaluate -1000 >> 2 in __max_diff_type we keep the MSB set, but leave the second-most-significant bit cleared. PR c++/108099 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Don't clear typedef_decl after 'unsigned typedef' pedwarn. Use c_common_signed_or_unsigned_type. Also handle 'signed typedef'. gcc/testsuite/ChangeLog: * g++.dg/ext/int128-8.C: New test. * g++.dg/ext/unsigned-typedef2.C: New test. * g++.dg/ext/unsigned-typedef3.C: New test.
2023-05-02c++: Move -Wdangling-reference to -Wextra [PR109642]Marek Polacek2-2/+3
Sadly, -Wdangling-reference generates false positives for std::span-like user classes, and it seems imprudent to attempt to improve the heuristic in GCC 13. Let's move the warning to -Wextra, that will hopefully reduce the number of false positives the users have been seeing with 13. I'm leaving the warning in -Wall in 14 where I think I can write code to detect std::span-like classes. PR c++/109642 PR c++/109640 PR c++/109671 gcc/c-family/ChangeLog: * c.opt (Wdangling-reference): Move from -Wall to -Wextra. gcc/ChangeLog: * doc/invoke.texi: Document that -Wdangling-reference is enabled by -Wextra.
2023-05-02testsuite: adjust NOP expectations for RISC-VJan Beulich3-3/+6
RISC-V will emit ".option nopic" when -fno-pie is in effect, which matches the generic pattern. Just like done for Alpha, special-case RISC-V. gcc/testsuite/ * c-c++-common/patchable_function_entry-decl.c: Special-case RISC-V. * c-c++-common/patchable_function_entry-default.c: Likewise. * c-c++-common/patchable_function_entry-definition.c: Likewise.
2023-05-02Daily bump.GCC Administrator1-1/+1
2023-05-01Daily bump.GCC Administrator1-1/+1
2023-04-30Daily bump.GCC Administrator1-1/+1
2023-04-29Daily bump.GCC Administrator2-1/+13
2023-04-28amdgcn: Fix addsub bugAndrew Stubbs1-8/+15
The vec_fmsubadd instuction actually had add twice, by mistake. Also improve code-gen for all the complex patterns by using properly undefined values. Mostly this just prevents the compiler reserving space in the stack frame. gcc/ChangeLog: * config/gcn/gcn-valu.md (cmul<conj_op><mode>3): Use gcn_gen_undef. (cml<addsub_as><mode>4): Likewise. (vec_addsub<mode>3): Likewise. (cadd<rot><mode>3): Likewise. (vec_fmaddsub<mode>4): Likewise. (vec_fmsubadd<mode>4): Likewise, and use sub for the odd lanes. (cherry picked from commit b17c57b06d90f2ca12ea0395046c4ea7d439065f)
2023-04-28Daily bump.GCC Administrator4-1/+44
2023-04-27Update gcc .po filesJoseph Myers19-37123/+37682
* be.po, da.po, de.po, el.po, es.po, fi.po, fr.po, hr.po, id.po, ja.po, nl.po, ru.po, sr.po, sv.po, tr.po, uk.po, vi.po, zh_CN.po, zh_TW.po: Update.
2023-04-27c: Fix up error-recovery on non-empty VLA initializers [PR109409]Jakub Jelinek2-4/+17
On the following testcase we ICE, because after we emit the variable-sized object may not be initialized except with an empty initializer error we don't really reset the initializer to error_mark_node and then at -Wformat checking time we ICE on seeing STRING_CST initializer for a VLA. The following patch just arranges for error_mark_node to be returned after the error diagnostics. 2023-04-27 Jakub Jelinek <jakub@redhat.com> PR c/109409 * c-parser.cc (c_parser_initializer): Move diagnostics about initialization of variable sized object with non-empty initializer after c_parser_expr_no_commas call and ret.set_error (); after it. * gcc.dg/pr109409.c: New test. (cherry picked from commit d8842271ebf9a81128df9ae80e1d3b688749eac8)
2023-04-27c: Fix up error-recovery on functions initialized as variables [PR109412]Jakub Jelinek2-0/+25
The change to allow empty initializers in C broke error-recovery on the following testcase. We are emitting function %qD is initialized like a variable error early; if the initializer is non-empty, we just emit another error that the initializer is invalid. Previously if it was empty, we'd emit another error that scalar is being initialized by empty initializer (not really correct), but now we instead just try to build_zero_cst for the FUNCTION_TYPE and ICE on it. The following patch just emits the same diagnostics for the empty initializers as we emit for the non-empty ones. 2023-04-27 Jakub Jelinek <jakub@redhat.com> PR c/107682 PR c/109412 * c-typeck.cc (pop_init_level): If constructor_type is FUNCTION_TYPE, reject empty initializer as invalid. * gcc.dg/pr109412.c: New test. (cherry picked from commit a1030fbf70eef5b635e4fbb904ec7209ebd137ca)
2023-04-27Daily bump.GCC Administrator4-1/+133
2023-04-26amdgcn: bug fix ldexp insnAndrew Stubbs1-16/+9
The vop3 instructions don't support B constraint immediates. Also, take the use the SV_FP iterator to delete a redundant pattern. gcc/ChangeLog: * config/gcn/gcn-valu.md (vnsi, VnSI): Add scalar modes. (ldexp<mode>3): Delete. (ldexp<mode>3<exec>): Change "B" to "A". (cherry picked from commit 0be4fbeaa6a7a2db466a6fd2efad2afdb642bac0)
2023-04-26amdgcn: update target-supports.expAndrew Stubbs1-5/+10
The backend can now vectorize more things. gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_effective_target_vect_call_copysignf): Add amdgcn. (check_effective_target_vect_call_sqrtf): Add amdgcn. (check_effective_target_vect_call_ceilf): Add amdgcn. (check_effective_target_vect_call_floor): Add amdgcn. (check_effective_target_vect_logical_reduc): Add amdgcn. (cherry picked from commit 09751f52bfa6757405c85faede627129fdd0884f)
2023-04-26amdgcn: HardFP divideAndrew Stubbs4-97/+144
Implement FP division using hardware instructions. This replaces both the softfp library calls, and the --fast-math inaccurate divsion we had previously. The GCN architecture does not have a single divide instruction, but it does have a number of support instructions designed to make multiply-by-reciprocal sufficiently accurate for non-fast-math usage. gcc/ChangeLog: * config/gcn/gcn-valu.md (SV_SFDF): New iterator. (SV_FP): New iterator. (scalar_mode, SCALAR_MODE): Add identity mappings for scalar modes. (recip<mode>2): Unify the two patterns using SV_FP. (div_scale<mode><exec_vcc>): New insn. (div_fmas<mode><exec>): New insn. (div_fixup<mode><exec>): New insn. (div<mode>3): Unify the two expanders and rewrite using hardfp. * config/gcn/gcn.cc (gcn_md_reorg): Support "vccwait" attribute. * config/gcn/gcn.md (unspec): Add UNSPEC_DIV_SCALE, UNSPEC_DIV_FMAS, and UNSPEC_DIV_FIXUP. (vccwait): New attribute. gcc/testsuite/ChangeLog: * gcc.target/gcn/fpdiv.c: Remove the -ffast-math requirement. (cherry picked from commit cfdc45f73c56ad051a53576a4e88675ced2660d4)
2023-04-26tree-optimization/109609 - correctly interpret arg size in fnspecRichard Biener3-5/+43
By majority vote and a hint from the API name which is arg_max_access_size_given_by_arg_p this interprets a memory access size specified as given as other argument such as for strncpy in the testcase which has "1cO313" as specifying the _maximum_ size read/written rather than the exact size. There are two uses interpreting it that way already and one differing. The following adjusts the differing and clarifies the documentation. PR tree-optimization/109609 * attr-fnspec.h (arg_max_access_size_given_by_arg_p): Clarify semantics. * tree-ssa-alias.cc (check_fnspec): Correctly interpret the size given by arg_max_access_size_given_by_arg_p as maximum, not exact, size. * gcc.dg/torture/pr109609.c: New testcase. (cherry picked from commit e8d00353017f895d03a9eabae3506fd126ce1a2d)
2023-04-26rtl-optimization/109585 - alias analysis typoRichard Biener2-1/+34
When r10-514-gc6b84edb6110dd2b4fb improved access path analysis it introduced a typo that triggers when there's an access to a trailing array in the first access path leading to false disambiguation. PR rtl-optimization/109585 * tree-ssa-alias.cc (aliasing_component_refs_p): Fix typo. * gcc.dg/torture/pr109585.c: New testcase. (cherry picked from commit 6d4bd27a60447c7505cb4783e675e98a191a8904)
2023-04-26tree-optimization/109573 - avoid ICEing on unexpected live defRichard Biener2-3/+95
The following relaxes the assert in vectorizable_live_operation where we catch currently unhandled cases to also allow an intermediate copy as it happens here but also relax the assert to checking only. PR tree-optimization/109573 * tree-vect-loop.cc (vectorizable_live_operation): Allow unhandled SSA copy as well. Demote assert to checking only. * g++.dg/vect/pr109573.cc: New testcase. (cherry picked from commit cddfe6bc40b3dc0806e260bbfb4cac82d609a258)
2023-04-26testsuite: Fix up ext-floating2.C on powerpc64-linuxJakub Jelinek1-0/+4
Another testcase that is failing on powerpc64-linux. The test expects a diagnostics when float64 && float128 or in another spot when float32 && float128. Now, float128 effective target is satisfied on powerpc64-linux, despite __CPP_FLOAT128_T__ not being defined, because one needs to add some extra options for it. I think 32-bit arm has similar case for float16. 2023-04-25 Jakub Jelinek <jakub@redhat.com> * g++.dg/cpp23/ext-floating2.C: Add dg-add-options for float16, float32, float64 and float128. (cherry picked from commit 78aaaf862e70cea45f3a2be7cb855cfe1a4ead21)
2023-04-26testsuite: Fix up ext-floating15.C tests on powerpc64-linux [PR109278]Jakub Jelinek1-0/+1
I've noticed this test FAILs on powerpc64-linux, with FAIL: g++.dg/cpp23/ext-floating15.C -std=gnu++98 (test for excess errors) Excess errors: /home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:5: error: '_Float128' is not supported on this target /home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:5: error: '_Float128' is not supported on this target /home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:1: error: variable or field 'bar' declared void /home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:5: error: '_Float128' is not supported on this target /home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:6: error: expected primary-expression before '_Float128' and similarly other std versions. powerpc64-linux is float128 target, but needs to add some options for it. Fixed by adding them. 2023-04-25 Jakub Jelinek <jakub@redhat.com> PR c++/109278 * g++.dg/cpp23/ext-floating15.C: Add dg-add-options float128. (cherry picked from commit 784e03f378bb2c330b96459928d0472d38748970)
2023-04-26c: Avoid -Wenum-int-mismatch warning for redeclaration of builtin ↵Jakub Jelinek2-1/+31
acc_on_device [PR107041] The new -Wenum-int-mismatch warning triggers with -Wsystem-headers in <openacc.h>, for obvious reasons the builtin acc_on_device uses int type argument rather than enum which isn't defined yet when the builtin is created, while the OpenACC spec requires it to have acc_device_t enum argument. The header makes sure it has int underlying type by using negative and __INT_MAX__ enumerators. I've tried to make the builtin typegeneric or just varargs, but that changes behavior e.g. when one calls it with some C++ class which has cast operator to acc_device_t, so the following patch instead disables the warning for this builtin. 2023-04-20 Jakub Jelinek <jakub@redhat.com> PR c/107041 * c-decl.cc (diagnose_mismatched_decls): Avoid -Wenum-int-mismatch warning on acc_on_device declaration. * gcc.dg/goacc/pr107041.c: New test. (cherry picked from commit 3d7ab53d6c59499624aa41c8dea0664976820b3b)
2023-04-26Bump BASE-VERJakub Jelinek1-1/+1
2023-04-26 Jakub Jelinek <jakub@redhat.com> * BASE-VER: Set to 13.1.1.
2023-04-26Update ChangeLog and version files for releasereleases/gcc-13.1.0Jakub Jelinek19-2/+69
2023-04-26Daily bump.GCC Administrator4-1/+23
2023-04-25Regenerate gcc.potJoseph Myers1-1951/+1976
* gcc.pot: Regenerate.
2023-04-25powerpc: Fix up *branch_anddi3_dot for -m32 -mpowerpc64 [PR109566]Jakub Jelinek2-1/+28
The following testcase reduced from newlib ICEs on powerpc-linux, with -O2 -m32 -mpowerpc64 since r12-6433 PR102239 optimization was added and on the original testcase since some ranger improvements in GCC 13 made it no longer latent on newlib. The problem is that the *branch_anddi3_dot define_insn_and_split relies on the *rotldi3_mask_dot define_insn_and_split being recognized during splitting. The rs6000_is_valid_rotate_dot_mask function checks whether the mask is a CONST_INT which is a valid mask, but *rotl<mode>3_mask_dot in addition to checking that it is a valid mask also has (<MODE>mode == Pmode || UINTVAL (operands[3]) <= 0x7fffffff) test in the condition. For TARGET_64BIT that doesn't add any further requirements, but for !TARGET_64BIT && TARGET_POWERPC64 if the AND second operand is larger than INT_MAX it will not be recognized. The rs6000_is_valid_rotate_dot_mask function is used solely in one spot, condition of *branch_anddi3_dot, so the following patch adjusts it to check for that as well. 2023-04-25 Jakub Jelinek <jakub@redhat.com> PR target/109566 * config/rs6000/rs6000.cc (rs6000_is_valid_rotate_dot_mask): For !TARGET_64BIT, don't return true if UINTVAL (mask) << (63 - nb) is larger than signed int maximum. * gcc.target/powerpc/pr109566.c: New test. (cherry picked from commit 97f8f2d0a0384d377ca46da88495f9a3d18d4415)
2023-04-25Daily bump.GCC Administrator3-1/+26
2023-04-24Update gcc hr.po, sv.po, zh_CN.poJoseph Myers3-1146/+587
* hr.po, sv.po, zh_CN.po: Update.
2023-04-24doc: Update install.texi for GCC 13Rainer Orth1-109/+78
install.texi needs some updates for GCC 13 and trunk: * We used a mixture of Solaris 2 and Solaris references. Since Solaris 1/SunOS 4 is ancient history by now, consistently use Solaris everywhere. Likewise, explicit references to Solaris 11 can go in many places since Solaris 11.3 and 11.4 is all GCC supports. * Some caveats apply to both Solaris/SPARC and x86, like the difference between as and gas. * Some specifics are obsolete, like the /usr/ccs/bin path whose contents was merged into /usr/bin in Solaris 11.0 already. Likewise, /bin/sh is ksh93 since Solaris 11.0, so there's no need to explicitly use /bin/ksh. * I've removed the reference to OpenCSW: there's barely a need for external sites to get additional packages. OpenCSW is mostly unmaintained these days and has been found to be rather harmful then helping. * The section on assembler and linker to use was partially duplicated. Better keep the info in one place. * GNAT is bundled in recent Solaris 11.4 updates, so recommend that. Tested on i386-pc-solaris2.11 with make doc/gccinstall.{info,pdf} and inspection of the latter. 2023-04-21 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> gcc: * doc/install.texi: Consistently use Solaris rather than Solaris 2. Remove explicit Solaris 11 references. Markup fixes. (Options specification, --with-gnu-as): as and gas always differ on Solaris. Remove /usr/ccs/bin reference. (Installing GCC: Binaries, Solaris (SPARC, Intel)): Remove. (i?86-*-solaris2*): Merge assembler, linker recommendations ... (*-*-solaris2*): ... here. Update bundled GCC versions. Don't refer to pre-built binaries. Remove /bin/sh warning. Update assembler, linker recommendations. Document GNAT bootstrap compiler. (sparc-sun-solaris2*): Remove non-UltraSPARC reference. (sparc64-*-solaris2*): Move content... (sparcv9-*-solaris2*): ...here. Add GDC for 64-bit bootstrap compilers.
2023-04-24Daily bump.GCC Administrator1-1/+1
2023-04-23Daily bump.GCC Administrator3-1/+18
2023-04-22match.pd: Fix fneg/fadd optimization [PR109583]Jakub Jelinek2-1/+27
The following testcase ICEs on x86, foo function since my r14-22 improvement, but bar already since r13-4122. The problem is the same, in the if expression related_vector_mode is called and that starts with gcc_assert (VECTOR_MODE_P (vector_mode)); but nothing in the fneg/fadd match.pd pattern actually checks if the VEC_PERM type has VECTOR_MODE_P (vec_mode). In this case it has BLKmode and so it ICEs. The following patch makes sure we don't ICE on it. 2023-04-22 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/109583 * match.pd (fneg/fadd simplify): Don't call related_vector_mode if vec_mode is not VECTOR_MODE_P. * gcc.dg/pr109583.c: New test. (cherry picked from commit c58c0771b7a3dbd2a00cd4b6ca2301d74b6cd4e2)
2023-04-22Daily bump.GCC Administrator3-1/+28
2023-04-21LoongArch: Add built-in functions description of LoongArch Base instruction ↵Lulu Cheng1-0/+129
set instructions. gcc/ChangeLog: * doc/extend.texi: Add section for LoongArch Base Built-in functions. (cherry picked from commit 5015cdf3155c80e5fd61f7b6ab8082ee849e3e90)
2023-04-21Do not ignore UNDEFINED ranges when determining PHI equivalences.Andrew MacLeod5-10/+117
Do not ignore UNDEFINED name arguments when registering two-way equivalences from PHIs. PR tree-optimization/109564 gcc/ * gimple-range-fold.cc (fold_using_range::range_of_phi): Do no ignore UNDEFINED range names when deciding if all PHI arguments are the same, gcc/testsuite/ * gcc.dg/torture/pr109564-1.c: New testcase. * gcc.dg/torture/pr109564-2.c: Likewise. * gcc.dg/tree-ssa/evrp-ignore.c: XFAIL. * gcc.dg/tree-ssa/vrp06.c: Likewise. (cherry picked from commit 17aa9ddb34581855dd013745c8be27dda024de4a)
2023-04-21Daily bump.GCC Administrator2-1/+6
2023-04-20doc: Remove repeated word (typo)Alejandro Colomar1-1/+1
gcc/ChangeLog: * doc/extend.texi (Common Function Attributes): Remove duplicate word. Signed-off-by: Alejandro Colomar <alx@kernel.org>
2023-04-20Daily bump.GCC Administrator4-1/+59
2023-04-19c++: bad ggc_free in try_class_unification [PR109556]Patrick Palka2-5/+18
Aside from correcting how try_class_unification copies multi-dimensional 'targs', r13-377-g3e948d645bc908 also made it ggc_free this copy as an optimization. But this is wrong since the call to unify within might've captured the args in persistent memory such as the satisfaction cache (as part of constrained auto deduction). PR c++/109556 gcc/cp/ChangeLog: * pt.cc (try_class_unification): Don't ggc_free the copy of 'targs'. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-placeholder13.C: New test. (cherry picked from commit 5e284ebbc3082c5a8974d24e3a0977aa48f3cc60)
generated by cgit v1.1 at 2025-09-23 12:43:35 +0000