This project is mirrored from git://gcc.gnu.org/git/gcc.git.
Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
- 08 Apr, 2020 2 commits
-
-
Joey Ye authored
2019-09-11 Wilco Dijkstra <wdijkstr@arm.com> PR tree-optimization/80155 * common/config/arm/arm-common.c (arm_option_optimization_table): Enable -fcode-hoisting with -Os. -
GCC Administrator authored
-
- 07 Apr, 2020 26 commits
-
-
Will Schmidt authored
2020-04-07 Will Schmidt <will_schmidt@vnet.ibm.com> Backport from mainline. 2020-03-23 Will Schmidt <will_schmidt@vnet.ibm.com> * config/rs6000/rs6000-call.c altivec_init_builtins(): Remove code to skip defining builtins based on builtin_mask. * gcc.target/powerpc/pragma_power6.c: New. * gcc.target/powerpc/pragma_power7.c: New. * gcc.target/powerpc/pragma_power8.c: New. * gcc.target/powerpc/pragma_power9.c: New. * gcc.target/powerpc/pragma_misc9.c: New. * gcc.target/powerpc/vsu/pragma_misc9.c: New. * gcc.target/powerpc/vsu/vec-all-nez-7.c: Update. * gcc.target/powerpc/vsu/vec-any-eqz-7.c: Update. -
Jakub Jelinek authored
The following testcases are miscompiled, because expand_vec_perm_pshufb incorrectly thinks it can use vpshufb instruction for the permutations when it can't. The if (vmode == V32QImode) { /* vpshufb only works intra lanes, it is not possible to shuffle bytes in between the lanes. */ for (i = 0; i < nelt; ++i) if ((d->perm[i] ^ i) & (nelt / 2)) return false; } intra-lane check which is correct has been copied and adjusted for 64-byte modes into: if (vmode == V64QImode) { /* vpshufb only works intra lanes, it is not possible to shuffle bytes in between the lanes. */ for (i = 0; i < nelt; ++i) if ((d->perm[i] ^ i) & (nelt / 4)) return false; } which is not correct, because 64-byte modes have 4 lanes rather than just two and the above is only testing that the permutation grabs even lane elts from even lanes and odd lane elts from odd lanes, but not that they are from the same 256-bit half. The following patch fixes it by using 3 * nelt / 4 instead of nelt / 4, so we actually check the most significant 2 bits rather than just one. 2020-04-07 Jakub Jelinek <jakub@redhat.com> PR target/94509 * config/i386/i386-expand.c (expand_vec_perm_pshufb): Fix the check for inter-lane permutation for 64-byte modes. * gcc.target/i386/avx512bw-pr94509-1.c: New test. * gcc.target/i386/avx512bw-pr94509-2.c: New test. -
Jakub Jelinek authored
We need to set OMP_PARALLEL_COMBINED only if the parsing of omp_master succeeded, because otherwise there is no nested master construct in the parallel. 2020-04-07 Jakub Jelinek <jakub@redhat.com> PR c++/94512 * c-parser.c (c_parser_omp_parallel): Set OMP_PARALLEL_COMBINED if c_parser_omp_master succeeded. * parser.c (cp_parser_omp_parallel): Set OMP_PARALLEL_COMBINED if cp_parser_omp_master succeeded. * g++.dg/gomp/pr94512.C: New test.
-
Jakub Jelinek authored
The following testcase ICEs on aarch64 apparently since the introduction of the aarch64 port. The reason is that the {ashl,ashr,lshr}<mode>3 expanders completely unnecessarily FAIL; if operands[2] is something other than a CONST_INT or REG or MEM and the middle-end code can't cope with the pattern giving up in these cases. All the expanders use general_operand predicate for the shift amount operand, but then have just a special case for CONST_INT (if in-bound, emit an immediate shift, otherwise force into REG), or MEM (force into REG), or REG (that is the case it handles). In the testcase, operands[2] is a lowpart SUBREG of a REG, which is valid general_operand. I don't see any reason what is magic about MEMs that it should be forced into REG and others like SUBREGs that it shouldn't, there isn't even a reason to check for !REG_P because force_reg will do nothing if the operand is already a REG, and otherwise can handle general_operand just fine. 2020-04-07 Jakub Jelinek <jakub@redhat.com> PR target/94488 * config/aarch64/aarch64-simd.md (ashl<mode>3, lshr<mode>3, ashr<mode>3): Force operands[2] into reg whenever it is not CONST_INT. Assume it is a REG after that instead of testing it and doing FAIL otherwise. Formatting fix. * gcc.c-torture/compile/pr94488.c: New test. -
Jakub Jelinek authored
On the following testcase, in gdb ptype S<long>::m1 prints long as return type, but all the other methods show void instead. PR53756 added code to add_type_attribute if the return type is auto/decltype(auto), but we actually should look through references, pointers and qualifiers. Haven't included there DW_TAG_atomic_type, because I think at least ATM one can't use that in C++. Not sure about DW_TAG_array_type or what else could be deduced. > http://eel.is/c++draft/dcl.spec.auto#3 says it has to appear as a > decl-specifier. > > http://eel.is/c++draft/temp.deduct.type#8 lists the forms where a template > argument can be deduced. > > Looks like you are missing arrays, pointers to members, and function return > types. 2020-04-04 Hannes Domani <ssbssa@yahoo.de> Jakub Jelinek <jakub@redhat.com> PR debug/94459 * dwarf2out.c (gen_subprogram_die): Look through references, pointers, arrays, pointer-to-members, function types and qualifiers when checking if in-class DIE had an 'auto' or 'decltype(auto)' return type to emit type again on definition. * g++.dg/debug/pr94459.C: New test. Co-Authored-By:
Hannes Domani <ssbssa@yahoo.de>
-
Jakub Jelinek authored
The following testcase ICEs, because for parallel combined with some other construct we initialize the omp_parallel_combined_clauses pointer and expect the construct combined with it to clear it after it no longer needs it, but OMP_MASTER didn't do that. 2020-04-04 Jakub Jelinek <jakub@redhat.com> PR c++/94477 * pt.c (tsubst_expr) <case OMP_MASTER>: Clear omp_parallel_combined_clauses. * g++.dg/gomp/pr94477.C: New test.
-
Jakub Jelinek authored
The following testcase is miscompiled, because the AVX2 patterns don't describe correctly what the insn does. E.g. vphaddd with %ymm* operands (the second pattern) instruction as per: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_hadd_epi32&expand=2941 does { a0+a1, a2+a3, b0+b1, b2+b3, a4+a5, a6+a7, b4+b5, b6+b7 } but our RTL pattern did { a0+a1, a2+a3, a4+a5, a6+a7, b0+b1, b2+b3, b4+b5, b6+b7 } where the first and last 64 bits are the same and two middle 64 bits swapped. https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_hadd_epi16&expand=2939 similarly, insn does: { a0+a1, a2+a3, a4+a5, a6+a7, b0+b1, b2+b3, b4+b5, b6+b7, a8+a9, a10+a11, a12+a13, a14+a15, b8+b9, b10+b11, b12+b13, b14+b15 } but RTL pattern did { a0+a1, a2+a3, a4+a5, a6+a7, a8+a9, a10+a11, a12+a13, a14+a15, b0+b1, b2+b3, b4+b5, b6+b7, b8+b9, b10+b11, b12+b13, b14+b15 } again, first and last 64 bits are the same and the two middle 64 bits swapped. 2020-04-03 Jakub Jelinek <jakub@redhat.com> PR target/94460 * config/i386/sse.md (avx2_ph<plusminus_mnemonic>wv16hi3, avx2_ph<plusminus_mnemonic>dv8si3): Fix up RTL pattern to do second half of first lane from first lane of second operand and first half of second lane from second lane of first operand. * gcc.target/i386/avx2-pr94460.c: New test.
-
Jakub Jelinek authored
The following testcase ICEs because the objsz pass calls replace_uses_by on SSA_NAME_OCCURS_IN_ABNORMAL_PHI SSA_NAME. The following patch instead of that calls replace_call_with_value, which will turn it into xyz_123(ab) = 234; 2020-04-01 Jakub Jelinek <jakub@redhat.com> PR middle-end/94423 * tree-object-size.c (pass_object_sizes::execute): Don't call replace_uses_by for SSA_NAME_OCCURS_IN_ABNORMAL_PHI lhs, instead call replace_call_with_value. * gcc.dg/ubsan/pr94423.c: New test.
-
Jakub Jelinek authored
The following testcase is miscompiled since 4.9, we treat unsigned vector types as if they were signed and "optimize" negations across it. 2020-03-31 Marc Glisse <marc.glisse@inria.fr> Jakub Jelinek <jakub@redhat.com> PR middle-end/94412 * fold-const.c (fold_binary_loc) <case TRUNC_DIV_EXPR>: Use ANY_INTEGRAL_TYPE_P instead of INTEGRAL_TYPE_P. * gcc.c-torture/execute/pr94412.c: New test. Co-authored-by:Marc Glisse <marc.glisse@inria.fr>
-
Jakub Jelinek authored
The following testcase ICEs, because the FE when processing the statement expression changes the .VEC_CONVERT internal fn CALL_EXPR into .PHI call. That is because the internal fn call is recorded in the base.u.ifn field, which overlaps base.u.bits.lang_flag_1 which is used for STMT_IS_FULL_EXPR_P, so this essentially does ifn |= 2 on little-endian. STMT_IS_FULL_EXPR_P bit is used in: cp-gimplify.c- if (STATEMENT_CODE_P (code)) cp-gimplify.c- { cp-gimplify.c- saved_stmts_are_full_exprs_p = stmts_are_full_exprs_p (); cp-gimplify.c- current_stmt_tree ()->stmts_are_full_exprs_p cp-gimplify.c: = STMT_IS_FULL_EXPR_P (*expr_p); cp-gimplify.c- } and pt.c- if (STATEMENT_CODE_P (TREE_CODE (t))) pt.c: current_stmt_tree ()->stmts_are_full_exprs_p = STMT_IS_FULL_EXPR_P (t); so besides being wrong on some other codes, it actually isn't beneficial at all to set it on anything else, so the following patch restricts it to trees with STATEMENT_CODE_P TREE_CODE. 2020-03-30 Jakub Jelinek <jakub@redhat.com> PR c++/94385 * semantics.c (add_stmt): Only set STMT_IS_FULL_EXPR_P on trees with STATEMENT_CODE_P code. * c-c++-common/pr94385.c: New test. -
Jakub Jelinek authored
The AVX512F documentation clearly states that in instructions where the destination is a memory only merging-masking is possible, not zero-masking, and the assembler enforces that. The testcase in this patch fails to assemble because of Error: unsupported masking for `vextracti32x8' on vextracti32x8 $0x0, %zmm1, -64(%rsp){%k1}{z} For the vector extraction patterns, we apparently have 7 *_maskm patterns that only accept memory destinations and rtx_equal_p merge-masking source for it, 7 *<mask_name> corresponding patterns that allow memory destination only for the non-masked cases (through <store_mask_constraint>), then 2 *<mask_name> patterns (lo ssehalf V16FI and lo ssehalf VI8F_256 ones) which do allow memory destination even for masked cases and are the cause of the testsuite failure, because we must not allow C constraint if the destination is m, and finally one pair of patterns (separate * and *_mask, hi ssehalf VI4F_256), which has another issue (for which I don't have a testcase though), where if it would match zero-masking with register destination, it wouldn't emit the needed {z} into assembly. The attached patch fixes those 3 issues only, perhaps more suitable for backporting. 2020-03-30 Jakub Jelinek <jakub@redhat.com> PR target/93069 * config/i386/sse.md (vec_extract_lo_<mode><mask_name>): Use <store_mask_constraint> instead of m in output operand constraint. (vec_extract_hi_<mode><mask_name>): Use <mask_operand2> instead of %{%3%}. * gcc.target/i386/avx512vl-pr93069.c: New test. * gcc.dg/vect/pr93069.c: New test. -
Jakub Jelinek authored
The following testcase FAILs with -fcompare-debug, because reassociate_bb mishandles the case when the last stmt in a bb has zero uses. In that case reassoc_remove_stmt (like gsi_remove) moves the iterator to the next stmt, i.e. gsi_end_p is true, which means the code sets the iterator back to gsi_last_bb. The problem is that the for loop does gsi_prev on that before handling the next statement, which means the former penultimate stmt, now last one, is not processed by reassociate_bb. Now, with -g, if there is at least one debug stmt at the end of the bb, reassoc_remove_stmt moves the iterator to that following debug stmt and we just do gsi_prev and continue with the former penultimate non-debug stmt, now last non-debug stmt. The following patch fixes that by not doing the gsi_prev in this case; there are too many continue; cases, so I didn't want to copy over the gsi_prev to all of them, so this patch uses a bool for that instead. The second gsi_end_p check isn't needed anymore, because when we don't do the undesirable gsi_prev after gsi = gsi_last_bb, the loop !gsi_end_p (gsi) condition will catch the removal of the very last stmt from a bb. 2020-03-28 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/94329 * tree-ssa-reassoc.c (reassociate_bb): When calling reassoc_remove_stmt on the last stmt in a bb, make sure gsi_prev isn't done immediately after gsi_last_bb. * gfortran.dg/pr94329.f90: New test.
-
Jakub Jelinek authored
The following testcase is miscompiled, because output_constructor doesn't output the initializer correctly. The FE creates {[1...2] = 9} in this case, and we emit .long 9; long 9; .zero 8 instead of the expected .zero 8; .long 9; .long 9. If the CONSTRUCTOR is {[1] = 9, [2] = 9}, output_constructor_regular_field has code to notice that the current location (local->total_bytes) is smaller than the location we want to write to (1*sizeof(elt)) and will call assemble_zeros to skip those. But RANGE_EXPRs are handled by a different function which didn't do this, so for RANGE_EXPRs we emitted them properly only if local->total_bytes was always equal to the location where the RANGE_EXPR needs to start. 2020-03-25 Jakub Jelinek <jakub@redhat.com> PR middle-end/94303 * varasm.c (output_constructor_array_range): If local->index RANGE_EXPR doesn't start at the current location in the constructor, skip needed number of bytes using assemble_zeros or assert we don't go backwards. PR middle-end/94303 * g++.dg/torture/pr94303.C: New test. -
Jakub Jelinek authored
> > This patch caused: > > > > gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c -O3 -g -fno-tree-dce -c > > during GIMPLE pass: ifcvt > > /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c: In function ‘broken030599’: > > /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c:2:1: internal compiler error: Segmentation fault > > Likely > > /* Delete dead statements. */ > gsi = gsi_start_bb (bb); > while (!gsi_end_p (gsi)) > { > > needs to instead work back-to-front for debug stmt adjustment to work Indeed, that seems to work. 2020-03-25 Richard Biener <rguenther@suse.de> Jakub Jelinek <jakub@redhat.com> PR debug/94283 * tree-if-conv.c (ifcvt_local_dce): Delete dead statements backwards. * gcc.dg/pr94283.c: New test. Co-authored-by:Richard Biener <rguenther@suse.de>
-
Jakub Jelinek authored
The following testcase shows -fcompare-debug bugs in ifcvt_local_dce, where the decisions what statements are needed is based also on debug stmt operands, which is wrong. So, this patch makes sure to never add debug stmt to the worklist, or never add an assign to worklist just because it is used in a debug stmt in another bb. 2020-03-24 Jakub Jelinek <jakub@redhat.com> PR debug/94283 * tree-if-conv.c (ifcvt_local_dce): For gimple debug stmts, just set GF_PLF_2, but don't add them to worklist. Don't add an assigment to worklist or set GF_PLF_2 just because it is used in a debug stmt in another bb. Formatting improvements. * gcc.target/i386/pr94283.c: New test.
-
Jakub Jelinek authored
The following testcase FAILs with -fcompare-debug, but not because -g vs. -g0 would make a difference, but because the second compilation is done with -w in order not to emit warnings twice and -w seems to affect the *.gkd dump content. This is because TREE_NO_WARNING flag, or warn_unused_function does affect not just whether a warning/pedwarn is printed, but also whether we set TREE_PUBLIC on such decls. The following patch makes sure we set it regardless of anything warning related (TREE_NO_WARNING or warn_unused_function). 2020-03-24 Jakub Jelinek <jakub@redhat.com> PR debug/94277 * cgraphunit.c (check_global_declaration): For DECL_EXTERNAL and non-TREE_PUBLIC non-DECL_ARTIFICIAL FUNCTION_DECLs, set TREE_PUBLIC regardless of whether TREE_NO_WARNING is set on it or whether warn_unused_function is true or not. * gcc.dg/pr94277.c: New test.
-
Jakub Jelinek authored
Unfortunately the patch broke +FAIL: gcc.dg/pr20245-1.c (internal compiler error) +FAIL: gcc.dg/pr20245-1.c (test for excess errors) +FAIL: gcc.dg/pr28419.c (internal compiler error) +FAIL: gcc.dg/pr28419.c (test for excess errors) on some targets (and under valgrind on the rest of them). Those functions don't have the opening { and so c_parser_compound_statement returned error_mark_node before initializing *endlocp. So, either we can initialize it in that case too: --- gcc/c/c-parser.c 2020-03-20 22:09:39.659411721 +0100 +++ gcc/c/c-parser.c 2020-03-21 09:36:44.455705261 +0100 @@ -5611,6 +5611,8 @@ c_parser_compound_statement (c_parser *p if we have just prepared to enter a function body. */ stmt = c_begin_compound_stmt (true); c_end_compound_stmt (brace_loc, stmt, true); + if (endlocp) + *endlocp = brace_loc; return error_mark_node; } stmt = c_begin_compound_stmt (true); or perhaps simpler initialize it to the function_start_locus at the beginning and have those functions without { have function_start_locus == function_end_locus like the __GIMPLE functions (where propagating the closing } seemed too difficult). 2020-03-23 Jakub Jelinek <jakub@redhat.com> PR gcov-profile/94029 PR c/94239 * c-parser.c (c_parser_declaration_or_fndef): Initialize endloc to the function_start_locus location. Don't do that afterwards for the __GIMPLE body parsing. -
Jakub Jelinek authored
On the following testcase we ICE because while DECL_STRUCT_FUNCTION (current_function_decl)->function_start_locus = c_parser_peek_token (parser)->location; and similarly DECL_SOURCE_LOCATION (fndecl) is set from some token's location, the end is set as: /* Store the end of the function, so that we get good line number info for the epilogue. */ cfun->function_end_locus = input_location; and the thing is that input_location is only very rarely set in the C FE (the primary spot that changes it is the cb_line_change/fe_file_change). Which means, e.g. for pretty much all C functions that are on a single line, function_start_locus column is > than function_end_locus column, and the testcase even has smaller line in function_end_locus because cb_line_change isn't performed while parsing multi-line arguments of a function-like macro. Attached are two possible fixes to achieve what the C++ FE does, in particular that cfun->function_end_locus is the locus of the closing } of the function. The first one updates input_location when we see a closing } of a compound statement (though any, not just the function body) and thus input_location in the finish_function call is what we need. The second instead propagates the location_t from the parsing of the outermost compound statement (the function body) to finish_function. The second one is this version. 2020-03-19 Jakub Jelinek <jakub@redhat.com> PR gcov-profile/94029 * c-tree.h (finish_function): Add location_t argument defaulted to input_location. * c-parser.c (c_parser_compound_statement): Add endlocp argument and set it to the locus of closing } if non-NULL. (c_parser_compound_statement_nostart): Return locus of closing }. (c_parser_parse_rtl_body): Likewise. (c_parser_declaration_or_fndef): Propagate locus of closing } to finish_function. * c-decl.c (finish_function): Add end_loc argument, use it instead of input_location to set function_end_locus. * gcc.misc-tests/gcov-pr94029.c: New test. -
Jakub Jelinek authored
Without the parser.c change we were ICEing on the testcase, because while the uses of the captured vars inside of the constructs were replaced with capture proxy decls, we didn't do that for decls in OpenMP clauses. With that fixed, we don't ICE anymore, but the testcase is miscompiled and FAILs at runtime. This is because the capture proxy decls have DECL_VALUE_EXPR and during gimplification we were gimplifying those to their DECL_VALUE_EXPRs. That is fine for shared vars, but for privatized ones we must not do that. So that is what the cp-gimplify.c changes do. Had to add a DECL_CONTEXT check before calling is_capture_proxy because some VAR_DECLs don't have DECL_CONTEXT set (yet) and is_capture_proxy relies on that being non-NULL always. 2020-03-19 Jakub Jelinek <jakub@redhat.com> PR c++/93931 * parser.c (cp_parser_omp_var_list_no_open): Call process_outer_var_ref on outer_automatic_var_p decls. * cp-gimplify.c (cxx_omp_disregard_value_expr): Return true also for capture proxy decls. * testsuite/libgomp.c++/pr93931.C: New test.
-
Jakub Jelinek authored
Two years ago, I've added support for up to 2 simple preparation statements in value_replacement, but the - && estimate_num_insns (assign, &eni_time_weights) + && estimate_num_insns (bb_seq (middle_bb), &eni_time_weights) change, meant that we compute the cost of all those statements rather than just the single assign that has been the single supported non-debug statement in the bb before, doesn't do what I thought would do, gimple_seq is just gimple * and thus it can't be really overloaded depending on whether we pass a single gimple * or a whole sequence. Which means in the last two years it doesn't count all the statements, but only the first one. With -g that happens to be a DEBUG_STMT, or it could be e.g. the first preparation statement which could be much cheaper than the actual assign. 2020-03-19 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/94211 * tree-ssa-phiopt.c (value_replacement): Use estimate_num_insns_seq instead of estimate_num_insns for bb_seq (middle_bb). Rename emtpy_or_with_defined_p variable to empty_or_with_defined_p, adjust all uses. * gcc.dg/pr94211.c: New test.
-
Jakub Jelinek authored
The following testcases ICE, because they contain extern variable declarations with incomplete enum types that is later completed and after that those variables are accessed. The ICEs are because the vars then may have incorrect DECL_MODE etc., e.g. in the first case the var has SImode DECL_MODE (the guessed mode for the enum), but the enum then actually has DImode because its enumerators don't fit into unsigned int. The following patch fixes it by using C_TYPE_INCOMPLETE_VARS not just on incomplete struct/union types, but also incomplete enum types. TYPE_VFIELD can't be used as it is TYPE_MIN_VALUE on ENUMERAL_TYPE, thankfully TYPE_LANG_SLOT_1 has been used in the C FE only on FUNCTION_TYPEs. 2020-03-17 Jakub Jelinek <jakub@redhat.com> PR c/94172 * c-tree.h (C_TYPE_INCOMPLETE_VARS): Define to TYPE_LANG_SLOT_1 instead of TYPE_VFIELD, and support it on {RECORD,UNION,ENUMERAL}_TYPE. (TYPE_ACTUAL_ARG_TYPES): Check that it is only used on FUNCTION_TYPEs. * c-decl.c (pushdecl): Push C_TYPE_INCOMPLETE_VARS also to ENUMERAL_TYPEs. (finish_incomplete_vars): New function, moved from finish_struct. Use relayout_decl instead of layout_decl. (finish_struct): Remove obsolete comment about C_TYPE_INCOMPLETE_VARS being TYPE_VFIELD. Use finish_incomplete_vars. (finish_enum): Clear C_TYPE_INCOMPLETE_VARS. Call finish_incomplete_vars. * c-typeck.c (c_build_qualified_type): Clear C_TYPE_INCOMPLETE_VARS also on ENUMERAL_TYPEs. * gcc.dg/pr94172-1.c: New test. * gcc.dg/pr94172-2.c: New test. -
Jakub Jelinek authored
The testcase shows some accepts-invalid (the ones without alignas) and ice-on-invalid-code (the ones with alignas) cases. If the enum doesn't have an underlying type and is not a definition, the caller retries to parse it as elaborated type specifier. E.g. for enum struct S s it will then pedwarn that elaborated type specifier shouldn't have the struct/class keywords. The problem is if the enum specifier is not followed by { when it has underlying type. In that case we have already called cp_parser_parse_definitely to end the tentative parsing started at the beginning of cp_parser_enum_specifier. But the cp_parser_error (parser, "expected %<;%> or %<{%>"); doesn't emit any error because the whole function is called from yet another tentative parse and the caller starts parsing the elaborated type specifier where the cp_parser_enum_specifier stopped (i.e. after the underlying type token(s)). The ultimate caller than commits the tentative parsing (and even if it wouldn't, it wouldn't know what kind of error to report). I think after seeing enum {,struct,class} : type not being followed by { or ;, there is no reason not to report it right away, as it can't be valid C++, which is what the patch does. Not sure if we shouldn't also return error_mark_node instead of NULL_TREE, so that the caller doesn't try to parse it as elaborated type specifier (the patch doesn't do that right now). Furthermore, while reading the code, I've noticed that parser->colon_corrects_to_scope_p is saved and set to false at the start of the function, but not restored back in some cases. Don't have a testcase where this would be a problem, but it just seems wrong. Either we can in the two spots replace return NULL_TREE; with { type = NULL_TREE; goto out; } or we could perhaps abuse warning_sentinel or create a special class with dtor to clean the flag up. And lastly, I've fixed some formatting issues in the function while reading it. 2020-03-17 Jakub Jelinek <jakub@redhat.com> PR c++/90995 * parser.c (cp_parser_enum_specifier): Use temp_override for parser->colon_corrects_to_scope_p, replace goto out with return. If scoped enum or enum with underlying type is not followed by { or ;, call cp_parser_commit_to_tentative_parse before calling cp_parser_error and make sure to return error_mark_node instead of NULL_TREE. Formatting fixes. * g++.dg/cpp0x/enum40.C: New test. -
Kyrylo Tkachov authored
2020-04-07 Kyrylo Tkachov <kyrylo.tkachov@arm.com> PR target/94518 2019-09-23 Richard Sandiford <richard.sandiford@arm.com> * config/aarch64/atomics.md (aarch64_store_exclusive_pair): Fix memmodel index. -
Iain Buclaw authored
This patch addresses two problems with TypeInfo initializer generation. 1. D array fields pointing to compiler generated data are referencing public symbols with no unique prefix, which can lead to duplicate definition errors in some hard to reduce cases. To avoid name clashes, all symbols that are generated for TypeInfo initializers now use the assembler name of the TypeInfo decl as a prefix. 2. An ICE would occur during LTO pass because these same decls are considered to be part of the same comdat group as the TypeInfo decl that it's referred by, despite itself being neither marked public nor comdat. This resulted in decls being added to the LTRANS partition out of order, triggering an assert when add_symbol_to_partition_1 attempted to add them again. To remedy, TREE_PUBLIC and DECL_COMDAT are now set on all generated symbols. gcc/d/ChangeLog: PR d/94240 * typeinfo.cc (class TypeInfoVisitor): Replace type_ field with decl_. (TypeInfoVisitor::TypeInfoVisitor): Set decl_. (TypeInfoVisitor::result): Update. (TypeInfoVisitor::internal_reference): New function. (TypeInfoVisitor::layout_string): Use internal_reference. (TypeInfoVisitor::visit (TypeInfoTupleDeclaration *)): Likewise. (layout_typeinfo): Construct TypeInfoVisitor with typeinfo decl. (layout_classinfo): Likewise.
-
Jakub Jelinek authored
The following testcase is miscompiled in 8.x, because emit_reduc_half is prepared to handle for 512-bit modes only i equal to 512, 256, 128 and 64. V32HImode also needs i equal to 32 and V64QImode i equal to 32 and 16, but emit_reduc_half in that case performs a redundant permutation exactly like i == 32. In 9+ the testcase works because Richard in r9-3393 changed the reduc_* expanders so that they actually don't call ix86_expand_reduc on 512-bit modes, but only 128-bit ones. The patch fixes emit_reduc_half to handle also i of 32 and 16 similarly to how V32QImode/V16HImode are handled for AVX2. I think it shouldn't hurt to fix the function even on the trunk and 9 branch even when nothing uses it ATM. 2020-04-07 Jakub Jelinek <jakub@redhat.com> PR target/94500 * config/i386/i386.c (emit_reduc_half): For V{64QI,32HI}mode handle i < 64 using avx512bw_lshrv4ti3. Formatting fixes. * gcc.target/i386/avx512bw-pr94500.c: New test. -
GCC Administrator authored
-
- 06 Apr, 2020 3 commits
-
-
Fritz Reese authored
gcc/fortran/ChangeLog: 2020-04-06 Fritz Reese <foreese@gcc.gnu.org> Backport from master Steven G. Kargl <kargl@gcc.gnu.org> PR fortran/93686 * decl.c (gfc_match_data): Handle data matching for derived type pointers. gcc/testsuite/ChangeLog: 2020-04-06 Fritz Reese <foreese@gcc.gnu.org> Backport from master. Steven G. Kargl <kargl@gcc.gnu.org> PR fortran/93686 * gfortran.dg/pr93686_1.f90: New test. * gfortran.dg/pr93686_2.f90: Likewise. * gfortran.dg/pr93686_3.f90: Likewise. * gfortran.dg/pr93686_4.f90: Likewise.
-
Marek Polacek authored
If we are going to use get_first_fn let's make sure we operate on is_overloaded_fn, as the rest of the codebase does, and if lookup finds any class-scope declaration, return early too. PR c++/93597 - ICE with lambda in operator function. * name-lookup.c (maybe_save_operator_binding): Check is_overloaded_fn. * g++.dg/cpp0x/lambda/lambda-93597.C: New test.
-
GCC Administrator authored
-
- 05 Apr, 2020 1 commit
-
-
GCC Administrator authored
-
- 04 Apr, 2020 3 commits
-
-
Jason Merrill authored
We skip over other conversion codes when mangling expressions, we should do the same with IMPLICIT_CONV_EXPR. gcc/cp/ChangeLog 2020-04-04 Jason Merrill <jason@redhat.com> PR c++/91377 * mangle.c (write_expression): Skip IMPLICIT_CONV_EXPR.
-
Jason Merrill authored
The testcase hit an ICE trying to expand a TARGET_EXPR temporary cached from the other lambda-expression. This patch fixes this in two ways: 1) Avoid reusing a TARGET_EXPR from another function. 2) Avoid ending up with a TARGET_EXPR at all; the use of 'p' had become <TARGET_EXPR<NON_LVALUE_EXPR<TARGET_EXPR ...>>>, which doesn't make any sense. gcc/cp/ChangeLog 2020-04-04 Jason Merrill <jason@redhat.com> PR c++/94453 * constexpr.c (maybe_constant_value): Use break_out_target_exprs. * expr.c (mark_use) [VIEW_CONVERT_EXPR]: Don't wrap a TARGET_EXPR in NON_LVALUE_EXPR.
-
GCC Administrator authored
-
- 03 Apr, 2020 5 commits
-
-
Jason Merrill authored
In this testcase, when we do a pack expansion of count_better_mins<nums>, nums appears both in the definition of count_better_mins and as its template argument. The intent is that we get a expansion over pairs of elements of the pack, i.e. less<2,2>, less<2,7>, less<7,2>, .... But if we substitute into the definition of count_better_mins when parsing the template, we end up with sum<less<nums,nums>...>, which never gives us less<2,7>. We could deal with this by somehow marking up the use of 'nums' as an argument for 'num', but it's simpler to mark the alias as complex, so we need to instantiate it later with all its arguments rather than replace it early with its expansion. gcc/cp/ChangeLog 2020-04-03 Jason Merrill <jason@redhat.com> PR c++/91966 * pt.c (complex_pack_expansion_r): New. (complex_alias_template_p): Use it.
-
Martin Jambor authored
This is non-trivial but rather straightforward backport of 29f23ed7 from master. See https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542390.html for more information. 2020-04-02 Martin Jambor <mjambor@suse.cz> PR tree-optimization/93435 * params.def (PARAM_SRA_MAX_PROPAGATIONS): New parameter. * tree-sra.c (propagation_budget): New variable. (budget_for_propagation_access): New function. (propagate_subaccesses_across_link): Use it. (propagate_all_subaccesses): Set up and destroy propagation_budget. * doc/invoke.texi (sra-max-propagations): New. testsuite/ * gcc.dg/tree-ssa/pr93435.c: New test.
-
Jonathan Wakely authored
It should be valid to use std::to_address on a past-the-end iterator, but the debug mode iterators do a check for dereferenceable in their operator->(). That check is generally useful, so rather than remove it this changes std::__to_address to identify a debug mode iterator and use base().operator->() to skip the check. Backport from mainline 2020-04-03 Jonathan Wakely <jwakely@redhat.com> PR libstdc++/93960 * include/bits/ptr_traits.h (__to_address): Add special case for debug iterators, to avoid dereferenceable check. * testsuite/20_util/to_address/1_neg.cc: Adjust dg-error line number. * testsuite/20_util/to_address/debug.cc: New test.
-
Martin Liska authored
Backport from mainline 2020-04-03 Martin Liska <mliska@suse.cz> PR ipa/94445 * ipa-icf-gimple.c (func_checker::compare_gimple_call): Compare type attributes for gimple_call_fntypes.
-
GCC Administrator authored
-