aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2022-06-13Daily bump.GCC Administrator1-1/+1
2022-06-12Daily bump.GCC Administrator3-1/+18
2022-06-11c++: value-dep but not type-dep decltype expr [PR105756]Patrick Palka2-17/+31
Here during ahead of time instantiation of the value-dependent but not type-dependent decltype expression (5 % N) == 0, cp_build_binary_op folds the operands of the == via cp_fully_fold, which performs speculative constexpr evaluation, and from which we crash for (5 % N) due to the value-dependence. Since the operand folding performed by cp_build_binary_op appears to be solely for sake of diagnosing overflow, and since these diagnostics are suppressed when in an unevaluated context, this patch avoids this crash by suppressing cp_build_binary_op's operand folding accordingly. PR c++/105756 gcc/cp/ChangeLog: * typeck.cc (cp_build_binary_op): Don't fold operands when c_inhibit_evaluation_warnings. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/decltype82.C: New test. (cherry picked from commit 0ecb6b906f215ec56df1a555139abe9ad95414fb)
2022-06-11Daily bump.GCC Administrator1-1/+1
2022-06-10Daily bump.GCC Administrator2-1/+5
2022-06-09Update gcc sv.poJoseph Myers1-1228/+302
* sv.po: Update.
2022-06-09Daily bump.GCC Administrator4-1/+35
2022-06-08c++: redeclared hidden friend take 2 [PR105852]Jason Merrill5-12/+44
My previous patch for 105761 avoided copying DECL_TEMPLATE_INFO from a friend to a later definition, but in this testcase we have first a non-friend declaration and then a definition, and we need to avoid copying in that case as well. But we do still want to set new_template_info to avoid GC trouble. With this change, the modules dump correctly identifies ::foo as a non-template function in tpl-friend-2_a.C. Along the way I noticed that the duplicate_decls handling of DECL_UNIQUE_FRIEND_P was backwards for templates, where we don't clobber DECL_LANG_SPECIFIC (olddecl) with DECL_LANG_SPECIFIC (newdecl) like we do for non-templates. PR c++/105852 PR c++/105761 gcc/cp/ChangeLog: * decl.cc (duplicate_decls): Avoid copying template info from non-templated friend even if newdecl isn't a definition. Correct handling of DECL_UNIQUE_FRIEND_P on templates. * pt.cc (non_templated_friend_p): New. * cp-tree.h (non_templated_friend_p): Declare it. gcc/testsuite/ChangeLog: * g++.dg/modules/tpl-friend-2_a.C: Adjust expected dump. * g++.dg/template/friend74.C: New test.
2022-06-08gcc: xtensa: fix PR target/105879Max Filippov1-5/+8
split_double operates with the 'word that comes first in memory in the target' terminology, while gen_lowpart operates with the 'value representing some low-order bits of X' terminology. They are not equivalent and must be dealt with differently on little- and big-endian targets. gcc/ PR target/105879 * config/xtensa/xtensa.md (movdi): Rename 'first' and 'second' to 'lowpart' and 'highpart' so that they match 'gen_lowpart' and 'gen_highpart' bitwise semantics and fix order of highpart and lowpart depending on target endianness. (cherry picked from commit e94c6dbfb57a862dd8a8685eabc4886ad1aaea25)
2022-06-08Fix insn does not satisfy its constraints: sse2_lshrv1ti3liuhongt1-3/+3
21114(define_insn_and_split "ssse3_palignrdi" 21115 [(set (match_operand:DI 0 "register_operand" "=y,x,Yv") 21116 (unspec:DI [(match_operand:DI 1 "register_operand" "0,0,Yv") 21117 (match_operand:DI 2 "register_mmxmem_operand" "ym,x,Yv") 21118 (match_operand:SI 3 "const_0_to_255_mul_8_operand")] 21119 UNSPEC_PALIGNR))] 21120 "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3" Alternative 2 requires Yw instead of Yv since it's splitted to vpsrldq which requires AVX512VL & AVX512BW for evex version. gcc/ChangeLog: PR target/105854 * config/i386/sse.md (ssse3_palignrdi): Change alternative 2 from Yv to Yw.
2022-06-08Daily bump.GCC Administrator1-1/+1
2022-06-07Daily bump.GCC Administrator1-1/+1
2022-06-06Daily bump.GCC Administrator1-1/+1
2022-06-05Daily bump.GCC Administrator1-1/+1
2022-06-04Daily bump.GCC Administrator4-1/+147
2022-06-03c++: redeclared hidden friend [PR105761]Jason Merrill2-2/+22
Here, when we see the second declaration of f we match it with the first one, copy over DECL_TEMPLATE_INFO, and then try to use it when parsing the definition, leading to confusion. PR c++/105761 gcc/cp/ChangeLog: * decl.cc (duplicate_decls): Don't copy DECL_TEMPLATE_INFO from a hidden friend. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn64.C: New test.
2022-06-02c++: constexpr empty aggr [PR105795]Jason Merrill2-5/+29
In this testcase, leaving ctx->ctor pointing to the enclosing object meant that evaluating the initializer for the subobject clobbered previous initializers for the enclosing object. So do update ctx->ctor, just don't add it to the enclosing object ctor. PR c++/105795 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_bare_aggregate): Always call init_subob_ctx. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-aggr-base1.C: New test.
2022-06-02RISC-V: Implement C[LT]Z_DEFINED_VALUE_AT_ZEROPhilipp Tomsich6-91/+72
The Zbb support has introduced ctz and clz to the backend, but some transformations in GCC need to know what the value of c[lt]z at zero is. This affects how the optab is generated and may suppress use of CLZ/CTZ in tree passes. Among other things, this is needed for the transformation of table-based ctz-implementations, such as in deepsjeng, to work (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838). Prior to this change, the test case from PR90838 would compile to on RISC-V targets with Zbb: myctz: lui a4,%hi(.LC0) ld a4,%lo(.LC0)(a4) neg a5,a0 and a5,a5,a0 mul a5,a5,a4 lui a4,%hi(.LANCHOR0) addi a4,a4,%lo(.LANCHOR0) srli a5,a5,58 sh2add a5,a5,a4 lw a0,0(a5) ret After this change, we get: myctz: ctz a0,a0 andi a0,a0,63 ret Testing this with deepsjeng_r (from SPEC 2017) against QEMU, this shows a clear reduction in dynamic instruction count: - before 1961888067076 - after 1907928279874 (2.75% reduction) This also merges the various target-specific test-cases (for x86-64, aarch64 and riscv) within gcc.dg/pr90838.c. This extends the macros (i.e., effective-target keywords) used in testing (lib/target-supports.exp) to reliably distinguish between RV32 and RV64 via __riscv_xlen (i.e., the integer register bitwidth) : testing for ILP32 could be misleading (as ILP32 is a valid memory model for 64bit systems). gcc/ChangeLog: * config/riscv/riscv.h (CLZ_DEFINED_VALUE_AT_ZERO): Implement. (CTZ_DEFINED_VALUE_AT_ZERO): Same. * doc/sourcebuild.texi: add documentation for RISC-V specific test target keywords gcc/testsuite/ChangeLog: * gcc.dg/pr90838.c: Add additional flags (dg-additional-options) when compiling for riscv64 and subsume gcc.target/aarch64/pr90838.c and gcc.target/i386/pr95863-2.c. * gcc.target/aarch64/pr90838.c: Removed. * gcc.target/i386/pr95863-2.c: Removed. * lib/target-supports.exp: Recognize RV32 or RV64 via XLEN Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Signed-off-by: Manolis Tsamis <manolis.tsamis@vrull.eu> Co-authored-by: Manolis Tsamis <manolis.tsamis@vrull.eu> (cherry picked from commit 16f7fcadac19dabd04a5abbe6601df52d22e9685)
2022-06-02tree-optimization/105786 - avoid strlen replacement for pointersRichard Biener2-0/+14
This avoids matching strlen to a pointer result, avoiding ICEing because of an integer adjustment using PLUS_EXPR on pointers. 2022-06-01 Richard Biener <rguenther@suse.de> PR tree-optimization/105786 * tree-loop-distribution.cc (loop_distribution::transform_reduction_loop): Only do strlen replacement for integer type reductions. * gcc.dg/torture/pr105786.c: New testcase. (cherry picked from commit 57a8fb92ac4161ebbf9381b009e8c5af843e3e5f)
2022-06-02tree-optimization/105726 - adjust array bound heuristicRichard Biener2-9/+29
There's heuristic to detect ptr[1].a[...] out of bound accesses reasoning that if ptr points to an array of aggregates a trailing incomplete array has to have size zero. The following more thoroughly constrains the cases this applies to avoid false positive diagnostics. 2022-05-25 Richard Biener <rguenther@suse.de> PR tree-optimization/105726 * gimple-ssa-warn-restrict.cc (builtin_memref::set_base_and_offset): Constrain array-of-flexarray case more. * g++.dg/warn/Warray-bounds-27.C: New testcase. (cherry picked from commit e7c482b08076bb299742883c4ffd65b31e33200c)
2022-06-02middle-end/105711 - properly handle CONST_INT when expanding bitfieldsRichard Biener2-9/+25
This is another place where we fail to pass down the mode of a CONST_INT. 2022-05-24 Richard Biener <rguenther@suse.de> PR middle-end/105711 * expmed.cc (extract_bit_field_as_subreg): Add op0_mode parameter and use it. (extract_bit_field_1): Pass down the mode of op0 to extract_bit_field_as_subreg. * gcc.target/i386/pr105711.c: New testcase. (cherry picked from commit 91c7c5edd2c1d31bf379be1d077b39644391cc31)
2022-06-02PR middle-end/105604 - ICE: in tree_to_shwi with vla in struct and sprintfMartin Sebor5-35/+368
gcc/ChangeLog: PR middle-end/105604 * gimple-ssa-sprintf.cc (set_aggregate_size_and_offset): Add comments. (get_origin_and_offset_r): Remove null handling. Handle variable array sizes. (get_origin_and_offset): Handle null argument here. Simplify. (alias_offset): Update comment. * pointer-query.cc (field_at_offset): Update comment. Handle members of variable-length types. gcc/testsuite/ChangeLog: PR middle-end/105604 * gcc.dg/Wrestrict-24.c: New test. * gcc.dg/Wrestrict-25.c: New test. * gcc.dg/Wrestrict-26.c: New test. Co-authored-by: Richard Biener <rguenther@suse.de> (cherry picked from commit 10d1986aee47c592f903527bb68546efc557735d)
2022-06-02RISC-V: Inhibit FP <--> int register moves via tune paramVineet Gupta2-0/+65
Under extreme register pressure, compiler can use FP <--> int moves as a cheap alternate to spilling to memory. This was seen with SPEC2017 FP benchmark 507.cactu: ML_BSSN_Advect.cc:ML_BSSN_Advect_Body() | fmv.d.x fa5,s9 # PDupwindNthSymm2Xt1, PDupwindNthSymm2Xt1 | .LVL325: | ld s9,184(sp) # _12469, %sfp | ... | .LVL339: | fmv.x.d s4,fa5 # PDupwindNthSymm2Xt1, PDupwindNthSymm2Xt1 | The FMV instructions could be costlier (than stack spill) on certain micro-architectures, thus this needs to be a per-cpu tunable (default being to inhibit on all existing RV cpus). Testsuite run with new test reports 10 failures without the fix corresponding to the build variations of pr105666.c | === gcc Summary === | | # of expected passes 123318 (+10) | # of unexpected failures 34 (-10) | # of unexpected successes 4 | # of expected failures 780 | # of unresolved testcases 4 | # of unsupported tests 2796 gcc/ChangeLog: * config/riscv/riscv.cc: (struct riscv_tune_param): Add fmv_cost. (rocket_tune_info): Add default fmv_cost 8. (sifive_7_tune_info): Ditto. (thead_c906_tune_info): Ditto. (optimize_size_tune_info): Ditto. (riscv_register_move_cost): Use fmv_cost for int<->fp moves. gcc/testsuite/ChangeLog: * gcc.target/riscv/pr105666.c: New test. Signed-off-by: Vineet Gupta <vineetg@rivosinc.com> (cherry picked from commit b646d7d279ae0c0d35564542d09866bf3e8afac0)
2022-06-02Daily bump.GCC Administrator3-1/+44
2022-06-01c++: auto and dependent member name [PR105734]Jason Merrill2-1/+16
In r12-3643 I improved our handling of type names after . or -> when unqualified lookup doesn't find anything, but it needs to handle auto specially. PR c++/105734 gcc/cp/ChangeLog: * parser.cc (cp_parser_postfix_dot_deref_expression): Use typeof if the expression has auto type. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/auto57.C: New test.
2022-06-01c++: auto function as function argument [PR105779]Jason Merrill3-4/+17
This testcase demonstrates that the issue in PR105623 is not limited to templates, so we should do the marking in a less template-specific place. PR c++/105779 gcc/cp/ChangeLog: * call.cc (resolve_args): Call mark_single_function here. * pt.cc (unify_one_argument): Not here. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn63.C: New test.
2022-06-01c++: constexpr init of union sub-aggr w/ base [PR105491]Patrick Palka6-4/+80
Here ever since r10-7313-gb599bf9d6d1e18, reduced_constant_expression_p in C++11/14 is rejecting the marked sub-aggregate initializer (of type S) W w = {.D.2445={.s={.D.2387={.m=0}, .b=0}}}; ^ ultimately because said initializer has CONSTRUCTOR_NO_CLEARING set, hence the function must verify that all fields of S are initialized. And before C++17 it doesn't expect to see base class fields (since next_initializable_field skips over them), so the presence thereof causes r_c_e_p to return false. The reason r10-7313-gb599bf9d6d1e18 causes this is because in that commit we began using CONSTRUCTOR_NO_CLEARING to precisely track whether we're in middle of activating a union member. This ends up affecting clear_no_implicit_zero, which recurses into sub-aggregate initializers only if the outer initializer has CONSTRUCTOR_NO_CLEARING set. After that commit, the outer union initializer above no longer has the flag set at this point and so clear_no_implicit_zero no longer recurses into the marked inner initializer. But arguably r_c_e_p should be able to accept the marked initializer regardless of whether CONSTRUCTOR_NO_CLEARING is set. The primary bug therefore seems to be that r_c_e_p relies on next_initializable_field which skips over base class fields in C++11/14. To fix this, this patch introduces a new helper function next_subobject_field which is like next_initializable_field except that it never skips base class fields, and makes r_c_e_p use it. This patch then renames next_initializable_field to next_aggregate_field (and makes it skip over vptr fields again). NB: This minimal backport of r13-211-g0c7bce0ac184c0 for 12.2 just adds next_subobject_field and makes reduced_constant_expression_p use it. PR c++/105491 gcc/cp/ChangeLog: * constexpr.cc (reduced_constant_expression_p): Use next_subobject_field instead. * cp-tree.h (next_subobject_field): Declare. * decl.cc (next_subobject_field): Define. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-union7.C: New test. * g++.dg/cpp0x/constexpr-union7a.C: New test. * g++.dg/cpp2a/constinit17.C: New test. (cherry picked from commit 0c7bce0ac184c057bacad9c8e615ce82923835fd)
2022-06-01Daily bump.GCC Administrator4-1/+54
2022-05-31c++: lambda in concept [PR105652]Jason Merrill2-5/+29
We currently check satisfaction in the context of the constrained declaration (which may be wrong, see PR104111). When checking C<int> for S<int>, we currently substitute into the lambda in the context of S<T> (rather than S<int>, which seems wrong if the above isn't wrong), so the new closure type thinks its context is S<T>, which confuses debug output. For the moment, let's work around all of this by overriding the context of the closure. PR c++/105652 gcc/cp/ChangeLog: * pt.cc (tsubst_lambda_expr): Don't let a namespace-scope lambda instantiate into a class-scope lambda. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-lambda20.C: New test.
2022-05-31c++: CTAD with alias and nested template [PR105655]Jason Merrill2-1/+29
Here, alias_ctad_tweaks expect tsubst_decl of a FUNCTION_DECL to return a FUNCTION_DECL. A reasonable expectation, but in this case we were replacing the template args of the class-scope deduction guide with equivalent args, so looking in the hash table we found the partial instantiation stored when instantiating A<int>, which is a TEMPLATE_DECL. It's fine for that to be what is stored, but tsubst_function_decl should never return it. PR c++/105655 gcc/cp/ChangeLog: * pt.cc (build_template_decl): Add assert. (tsubst_function_decl): Don't return a template. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/class-deduction-alias13.C: New test.
2022-05-31c++: deduction from auto fn [PR105623]Jason Merrill3-3/+26
Since my patch for PR90451, we defer mark_used of single functions as late as possible. And since my r12-1273, we keep BASELINK from lookup around rather than reconstruct it later. These both made us try to instantiate g with a function type that still had 'auto' as its return type. PR c++/105623 gcc/cp/ChangeLog: * decl2.cc (mark_used): Copy type from fn to BASELINK. * pt.cc (unify_one_argument): Call mark_single_function. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn62.C: New test.
2022-05-31c++: constexpr ref to array of array [PR102307]Jason Merrill2-5/+24
The problem here is that first check_initializer calls build_aggr_init_full_exprs, which does overload resolution, but then in the case of failed constexpr throws away the result and does it again in build_functional_cast. But in the first overload resolution, reshape_init_array_1 decided to reuse the inner CONSTRUCTORs because tf_error is set, so we know we're committed. But the second pass gets confused by the CONSTRUCTORs with non-init-list types. Fixed by avoiding a second pass: instead, pass the call from build_aggr_init to build_cplus_new, which will turn it into a TARGET_EXPR. I don't bother to change the object argument because it will be replaced later in simplify_aggr_init_expr. PR c++/102307 gcc/cp/ChangeLog: * decl.cc (check_initializer): Use build_cplus_new in case of constexpr failure. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-array2.C: New test.
2022-05-31d: Fix D lexer sometimes fails to compile code read from stdinIain Buclaw1-0/+4
As of gdc-12, the lexer expects there 4 bytes of zero padding at the end of the source buffer to mark the end of input. Sometimes when reading from stdin, the data at the end of input is garbage rather than zeroes. Fix that by explicitly calling memset past the end of the buffer. PR d/105544 gcc/d/ChangeLog: * d-lang.cc (d_parse_file): Zero padding past the end of the stdin buffer so the D lexer has a sentinel to stop parsing at. (cherry picked from commit a0bc7fd42136f124726985b1ab4dcde739cd260e)
2022-05-31Daily bump.GCC Administrator3-1/+78
2022-05-30ipa: Check cst type when propagating controled uses infoMartin Jambor2-6/+20
PR 105639 shows that code with type-mismatches can trigger an assert after runnning into a branch that was inteded only for references to variables - as opposed to references to functions. Fixed by moving the condition from the assert to the guarding if statement. gcc/ChangeLog: 2022-05-25 Martin Jambor <mjambor@suse.cz> PR ipa/105639 * ipa-prop.cc (propagate_controlled_uses): Check type of the constant before adding a LOAD reference. gcc/testsuite/ChangeLog: 2022-05-25 Martin Jambor <mjambor@suse.cz> PR ipa/105639 * gcc.dg/ipa/pr105639.c: New test. (cherry picked from commit f571596f8cd8fbad34305b4bec1a813620e0cbf0)
2022-05-30libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732]Jakub Jelinek1-0/+18
The first part of the following testcase (m1-m3 macros and its use) regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows, the problem isn't new, we can emit a CPP_PADDING token to avoid it from being adjacent to whatever comes after the __VA_OPT__ (in this case there is nothing afterwards, true). In most cases these CPP_PADDING tokens don't matter, all other callers of cpp_get_token_with_location either ignore CPP_PADDING tokens completely (e.g. c_lex_with_flags) or they just remember them and take them into account when printing stuff whether there should be added whitespace or not (scan_translation_unit + token_streamer::stream). So, I think we should just ignore CPP_PADDING tokens the same way in _cpp_parse_expr. 2022-05-27 Jakub Jelinek <jakub@redhat.com> PR preprocessor/105732 * expr.cc (_cpp_parse_expr): Handle CPP_PADDING by just another token. * c-c++-common/cpp/va-opt-10.c: New test. (cherry picked from commit 58a40e76ebadce78639644cd3d56e42b68336927)
2022-05-30fold-const: Fix up -fsanitize=null in C++ [PR105729]Jakub Jelinek2-0/+39
The following testcase triggers a false positive UBSan binding a reference to null diagnostics. In the FE we instrument conversions from pointer to reference type to diagnose at runtime if the operand of such a conversion is 0. The problem is that a GENERIC folding folds ((const struct Bar *) ((const struct Foo *) this)->data) + (sizetype) range_check (x) conversion to const struct Bar & by converting to that the first operand of the POINTER_PLUS_EXPR. But that changes when the -fsanitize=null binding to reference runtime check occurs. Without the optimization, it is invoked on the result of the POINTER_PLUS_EXPR, and as range_check call throws, that means it never triggers in the testcase. With the optimization, it checks whether this->data is NULL and it is. The following patch avoids that optimization during GENERIC folding when -fsanitize=null is enabled and it is a cast from non-REFERENCE_TYPE to REFERENCE_TYPE. 2022-05-27 Jakub Jelinek <jakub@redhat.com> PR sanitizer/105729 * fold-const.cc (fold_unary_loc): Don't optimize (X &) ((Y *) z + w) to (X &) z + w if -fsanitize=null during GENERIC folding. * g++.dg/ubsan/pr105729.C: New test. (cherry picked from commit e2f014fcefcd2ad56b31995329820bbd99072eae)
2022-05-30asan: Fix up instrumentation of assignments which are both loads and stores ↵Jakub Jelinek2-1/+47
[PR105714] On the following testcase with -Os asan pass sees: <bb 6> [local count: 354334800]: # h_21 = PHI <h_15(6), 0(5)> *c.3_5 = *d.2_4; h_15 = h_21 + 1; if (h_15 != 3) goto <bb 6>; [75.00%] else goto <bb 7>; [25.00%] <bb 7> [local count: 118111600]: *c.3_5 = MEM[(struct a *)&b + 12B]; _13 = c.3_5->x; return _13; It instruments the *c.3_5 = *d.2_4; assignment by adding .ASAN_CHECK (7, c.3_5, 4, 4); .ASAN_CHECK (6, d.2_4, 4, 4); before it (which later lowers to checking the corresponding shadow memory). But when considering instrumentation of *c.3_5 = MEM[(struct a *)&b + 12B]; it doesn't instrument anything, because it sees that *c.3_5 store is already instrumented in a dominating block and so there is no need to instrument *c.3_5 store again (i.e. add another .ASAN_CHECK (7, c.3_5, 4, 4); ). That is true, but misses the fact that we still want to instrument the MEM[(struct a *)&b + 12B] load. The following patch fixes that by changing has_stmt_been_instrumented_p to consider both store and load in the assignment if it does both (returning true iff both have been instrumented). That matches how we handle e.g. builtin calls, where we also perform AND of all the memory locs involved in the call. I've verified that we still don't add the redundant .ASAN_CHECK (7, c.3_5, 4, 4); call but just add _18 = &MEM[(struct a *)&b + 12B]; .ASAN_CHECK (6, _18, 4, 4); to instrument the load. 2022-05-25 Jakub Jelinek <jakub@redhat.com> PR sanitizer/105714 * asan.cc (has_stmt_been_instrumented_p): For assignments which are both stores and loads, return true only if both destination and source have been instrumented. * gcc.dg/asan/pr105714.c: New test. (cherry picked from commit af02daff557a0abbf5521c143f1cdda406848a9b)
2022-05-30pointer-query: Fix ICE with non-pointer param [PR105635]Jakub Jelinek2-1/+12
The gimple_parm_array_size function comment talks about pointe parameters but doesn't actually verify it, it checks whether an attribute is present on the function and then just uses TREE_TYPE (TREE_TYPE (var)) which assumes a pointer type (or in theory could work for ARRAY_TYPE but c-family languages which only have that attribute will never have ARRAY_TYPE parameters; and for VECTOR_TYPE/COMPLEX_TYPE it would mean something quite different). So, this patch punts early if var doesn't have pointer/reference type. 2022-05-19 Jakub Jelinek <jakub@redhat.com> PR c/105635 * pointer-query.cc (gimple_parm_array_size): Return NULL if var doesn't have pointer or reference type. * gcc.dg/pr105635.c: New test. (cherry picked from commit 3b4daa0b3c3d8eb2ac3b40ad6898f314ed4d7919)
2022-05-30Daily bump.GCC Administrator1-1/+1
2022-05-29Daily bump.GCC Administrator1-1/+1
2022-05-28Daily bump.GCC Administrator3-1/+17
2022-05-27c++: Fix ICE with -Wmismatched-tags [PR105725]Marek Polacek2-2/+13
Here we ICE with -Wmismatched-tags on something like template <class T> bool B<T, enable_if_t<is_class_v<class T::foo>>>; Specifically, the "class T::foo" bit. There, class_decl_loc_t::add gets a TYPENAME_TYPE as TYPE, rather than a class/union type, so checking TYPE_BEING_DEFINED will crash. I think it's OK to allow a TYPENAME_TYPE to slip into that function; we just shouldn't consider the 'class' tag redundant (which works as a 'typename'). In fact, every other compiler *requires* it. PR c++/105725 gcc/cp/ChangeLog: * parser.cc (class_decl_loc_t::add): Check CLASS_TYPE_P. gcc/testsuite/ChangeLog: * g++.dg/warn/Wmismatched-tags-10.C: New test. (cherry picked from commit d822f4bbd714c6595f70cc68888dcebecfb6662d)
2022-05-27Daily bump.GCC Administrator2-1/+16
2022-05-26RISC-V: Don't unconditionally add m,a,f,d in arch-canonicalizeSimon Cook1-1/+1
This solves an issue where rv32i, etc. are canonicalized to rv32imafd since the g->i addition of 'm', 'a', 'f', 'd' is not actually gated by whether the input was rv32g/rv64g. gcc/ChangeLog: * config/riscv/arch-canonicalize: Only add mafd extension if base was rv32/rv64g. (cherry picked from commit 63f198553d3940495bfaa49da30b2ce93375c916)
2022-05-26RISC-V: Fix wrong expansion for arch-canonicalizeKito Cheng1-3/+5
rv64gcv should exapnd into: rv64imafdcv_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b but we exapnd fd twice for now: rv64imafdfdcv_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b gcc/ChangeLog: * config/riscv/arch-canonicalize: Handle g correctly. (cherry picked from commit 27239e13b1ba383e2706231917062aa6e14150a8)
2022-05-26Daily bump.GCC Administrator1-1/+1
2022-05-25Daily bump.GCC Administrator3-1/+67
2022-05-24i386: Adjust -fzero-call-used-regs to always use XOR [PR101891]Qing Zhao26-192/+180
Currently on i386, -fzero-call-used-regs uses a pattern of: XOR regA,regA MOV regA,regB MOV regA,regC ... RET However, this introduces both a register ordering dependency (e.g. the CPU cannot clear regB without clearing regA first), and while greatly reduces available ROP gadgets, it does technically leave a set of "MOV" ROP gadgets at the end of functions (e.g. "MOV regA,regC; RET"). This patch will switch to always use XOR on i386: XOR regA,regA XOR regB,regB XOR regC,regC ... RET gcc/ChangeLog: PR target/101891 * config/i386/i386.cc (zero_call_used_regno_mode): use V2SImode as a generic MMX mode instead of V4HImode. (zero_all_mm_registers): Use SET to zero instead of MOV for zeroing scratch registers. (ix86_zero_call_used_regs): Likewise. gcc/testsuite/ChangeLog: * gcc.target/i386/zero-scratch-regs-1.c: Add -fno-stack-protector -fno-PIC. * gcc.target/i386/zero-scratch-regs-10.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-13.c: Add -msse. * gcc.target/i386/zero-scratch-regs-14.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-15.c: Add -fno-stack-protector -fno-PIC. * gcc.target/i386/zero-scratch-regs-16.c: Likewise. * gcc.target/i386/zero-scratch-regs-17.c: Likewise. * gcc.target/i386/zero-scratch-regs-18.c: Add -fno-stack-protector -fno-PIC, adjust mov to xor. * gcc.target/i386/zero-scratch-regs-19.c: Add -fno-stack-protector -fno-PIC. * gcc.target/i386/zero-scratch-regs-2.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-20.c: Add -msse. * gcc.target/i386/zero-scratch-regs-21.c: Add -fno-stack-protector -fno-PIC, Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-22.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-23.c: Likewise. * gcc.target/i386/zero-scratch-regs-26.c: Likewise. * gcc.target/i386/zero-scratch-regs-27.c: Likewise. * gcc.target/i386/zero-scratch-regs-28.c: Likewise. * gcc.target/i386/zero-scratch-regs-3.c: Add -fno-stack-protector. * gcc.target/i386/zero-scratch-regs-31.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-4.c: Add -fno-stack-protector -fno-PIC. * gcc.target/i386/zero-scratch-regs-5.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-6.c: Add -fno-stack-protector. * gcc.target/i386/zero-scratch-regs-7.c: Likewise. * gcc.target/i386/zero-scratch-regs-8.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-9.c: Add -fno-stack-protector. (cherry picked from commit 0b86943aca51175968e40bbb6f2662dfe3fbfe59)
2022-05-24Extend --with-zstd documentationBruno Haible1-4/+14
The patch that was so far added for documenting --with-zstd is pretty minimal: - it refers to undocumented options --with-zstd-include and --with-zstd-lib; - it suggests that --with-zstd can be used without an argument; - it does not clarify how this option applies to cross-compilation. How about adding the same details as for the --with-isl, --with-isl-include, --with-isl-lib options, mutatis mutandis? This patch does that. PR other/105527 gcc/ChangeLog: * doc/install.texi (Configuration): Add more details about --with-zstd. Document --with-zstd-include and --with-zstd-lib Signed-off-by: Bruno Haible <bruno@clisp.org> (cherry picked from commit 3677eb80b683cead7db972bc206fd2e75d997bd2)
generated by cgit v1.1 at 2025-09-24 07:39:41 +0000