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 .
- 27 May, 2020 1 commit
-
-
GCC Administrator authored
-
- 26 May, 2020 2 commits
-
-
Alexandre Oliva authored
The emulation of mffsl with mffs, used when !TARGET_P9_MISC, is going through the motions, but not storing the result in the given operands[0]; it rather modifies operands[0] without effect. It also creates a DImode pseudo that it doesn't use, overwriting subregs instead. The patch below fixes all of these, the indentation and a typo. I'm concerned about several issues in the mffsl testcase. First, I don't see that comparing the values as doubles rather than as long longs is desirable. These are FPSCR bitfields, not FP numbers. I understand mffs et al use double because they output to FP registers, and the bit patterns are subnormal FP numbers, so it works, but given the need for bit masking of at least one side, I'm changing the compare to long longs. Another issue with the test is that, if the compare fails, it calls mffsl again to print the value, as if it would yield the same result. But part of the FPSCR that mffsl (emulated with mffs or not) copies to the output FP register is the FPCC, so the fcmpu used to compare the result of the first mffsl will modify FPSCR and thus the result of the second mffsl call. After changing the compare, this is no longer the case, but I still think it's better to make absolutely sure what we print is what we compared. Yet another issue is that the test assumed the mffs bits that are not to be extracted by mffsl to be already zero, instead of masking them out explicitly. This is not about the mffs emulation in the mffsl implementation, but about the mffs use in the test proper. The bits appear to be zero indeed, as the bits left out are for sticky exceptions, but there are reserved parts of FPSCR that might turn out to be set in the future, so we're better off masking them out explicitly, otherwise those bits could cause the compare to fail. If some future mffsl is changed so that it copies additional nonzero bits, the test will fail, and then we'll have a chance to adjust it and the emulation. gcc/ChangeLog: PR target/94812 * config/rs6000/rs6000.md (rs6000_mffsl): Copy result to output operand in emulation. Don't overwrite pseudos. gcc/testsuite/ChangeLog: PR target/94812 * gcc.target/powerpc/test_mffsl.c: Call mffsl only once. Reinterpret the doubles as long longs for compares. Mask out mffs bits that are not expected from mffsl. (cherry picked from commit 50714f45)
-
GCC Administrator authored
-
- 25 May, 2020 5 commits
-
-
Jason Merrill authored
This is the same issue as PR86429, just in potential_constant_expression_1 rather than cxx_eval_constant_expression. As in that case, when we're trying to evaluate a constant expression within a lambda, we don't have a constant closure object to refer to, but we can try to refer directly to the captured variable. gcc/cp/ChangeLog 2020-05-05 Jason Merrill <jason@redhat.com> PR c++/90212 * constexpr.c (potential_constant_expression_1): In a lambda function, consider a captured variable directly.
-
Jason Merrill authored
For default member initializers in templates it's important to push into the right context during get_nsdmi. But for a local class that's not possible, and trying leaves the function context we need to be in, so don't try. gcc/cp/ChangeLog 2020-05-01 Jason Merrill <jason@redhat.com> PR c++/90479 * init.c (get_nsdmi): Don't push_to_top_level for a local class.
-
Jason Merrill authored
cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that have non-constant construction or destruction, but -fmerge-all-constants was converting an automatic variable to static while leaving TREE_READONLY set. Fixed by clearing the flag in cp_finish_decl in the presence of -fmerge-all-constants. gcc/cp/ChangeLog 2020-05-01 Jason Merrill <jason@redhat.com> PR c++/91529 * decl.c (cp_finish_decl): Also clear TREE_READONLY if -fmerge-all-constants.
-
Jason Merrill authored
Within the generic lambda the VLA capture proxy VAR_DECL has DECL_VALUE_EXPR which is a NOP_EXPR to the VLA type of the proxy. The problem here was that when instantiating we were tsubsting that type twice, once for the type of the DECL and once for the type of the NOP_EXPR, and getting two different (though equivalent) types. Then gimplify_type_sizes fixed up the type of the DECL, but that didn't affect the type of the NOP_EXPR, leading to sadness. Fixed by directly reusing the type from the DECL. gcc/cp/ChangeLog 2020-05-01 Jason Merrill <jason@redhat.com> PR c++/93822 * pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have the same type as the variable.
-
GCC Administrator authored
-
- 24 May, 2020 2 commits
-
-
GCC Administrator authored
- 23 May, 2020 1 commit
-
-
GCC Administrator authored
-
- 22 May, 2020 3 commits
-
-
Thomas Koenig authored
2020-05-14 Thomas Koenig <tkoenig@gcc.gnu.org> PR libfortran/95119 * io/close.c (close_status): Add CLOSE_INVALID. (st_close): Return early on invalid STATUS parameter. 2020-05-14 Thomas Koenig <tkoenig@gcc.gnu.org> PR libfortran/95119 * testsuite/libgomp.fortran/close_errors_1.f90: New test. (cherry picked from commit cdc34b50) (cherry picked from commit d975519a) (cherry picked from commit 8275e0a6)
-
Bin Cheng authored
Current data dependence analysis misses unit distant vector if DRs in DDR have the same invariant access functions. This adds the vector as the constant access function case. Also fix typo in testcase. Backport from master. 2020-05-13 Bin Cheng <bin.cheng@linux.alibaba.com> gcc/ PR tree-optimization/94969 * tree-data-ref.c (constant_access_functions): Rename to... (invariant_access_functions): ...this. Add parameter. Check for invariant access function, rather than constant. (build_classic_dist_vector): Call above function. * tree-loop-distribution.c (pg_add_dependence_edges): Add comment. gcc/testsuite/ PR tree-optimization/94969 * gcc.dg/tree-ssa/pr94969.c: New test. 2020-05-13 Jakub Jelinek <jakub@redhat.com> gcc/testsuite/ PR tree-optimization/95110 * gcc.dg/tree-ssa/pr94969.c: Swap scan-tree-dump-not arguments.
-
GCC Administrator authored
-
- 21 May, 2020 4 commits
-
-
Martin Liska authored
gcc/ChangeLog: * common/config/aarch64/aarch64-common.c (aarch64_handle_option): Use MASK_OUTLINE_ATOMICS for x_target_flags. (cherry picked from commit f26cfe27)
-
Martin Liska authored
* common/config/aarch64/aarch64-common.c (aarch64_handle_option): Handle OPT_moutline_atomics. * config/aarch64/aarch64.c: Add outline-atomics to aarch64_attributes. * doc/extend.texi: Document the newly added target attribute. * gcc.target/aarch64/target_attr_20.c: New test. * gcc.target/aarch64/target_attr_21.c: New test. (cherry picked from commit 9e02b45f)
-
GCC Administrator authored
-
- 20 May, 2020 2 commits
-
-
Mark Eggleston authored
The value 'ppr@' is set in the name of result symbol, the actual name of the symbol is in the procedure name symbol pointed to by the result symbol's namespace (ns). When reporting errors for symbols that have the proc_pointer attribute check whether the result attribute is set and set the name accordingly. Backported from master. 2020-05-20 Mark Eggleston <markeggleston@gcc.gnu.org> gcc/fortran/ PR fortran/39695 * resolve.c (resolve_fl_procedure): Set name depending on whether the result attribute is set. For PROCEDURE/RESULT conflict use the name in sym->ns->proc_name->name. * symbol.c (gfc_add_type): Add check for function and result attributes use sym->ns->proc_name->name if both are set. Where the symbol cannot have a type use the name in sym->ns->proc_name->name. 2020-05-20 Mark Eggleston <markeggleston@gcc.gnu.org> gcc/testsuite/ PR fortran/39695 * gfortran.dg/pr39695_1.f90: New test. * gfortran.dg/pr39695_2.f90: New test. * gfortran.dg/pr39695_3.f90: New test. * gfortran.dg/pr39695_4.f90: New test. (cherry picked from commit eb069ae8)
-
GCC Administrator authored
-
- 19 May, 2020 2 commits
-
-
H.J. Lu authored
Update GFNI check to support processors with SSE and AVX versions of GFNI. Backport from master PR target/95220 * config/i386/cpuinfo.c (get_available_features): Fix FEATURE_GFNI check.
-
GCC Administrator authored
-
- 18 May, 2020 3 commits
-
-
Douglas Rupp authored
We're getting an error when running this test on PowerPC VxWorks 7, due to an unexpected warning: | Excess errors: | cc1: warning: '-mvsx' and '-mno-altivec' are incompatible The warning comes from a combination of factors: - The test itself uses -mvsx explicitly via the following directive: // { dg-options "-O1 -mvsx" } - Our toolchain was configured so as to make -mno-altivec the default; - These two options are mutually exclusive. This commit adds a powerpc_vsx_ok dg-require-effective-target directive to that test, and thus making it UNSUPPORTED instead. Tested on PowerPC VxWorks 7. Also tested on PowerPC ELF as well, a platform where we do not make -mno-altivec the default, to verify that the test continues to run as usual in that case. gcc/testsuite/ * gcc.target/powerpc/pr71763.c: Require powerpc_vsx_ok. (cherry picked from commit c917584a) -
Iain Buclaw authored
gcc/d/ChangeLog: PR d/92216 * decl.cc (make_thunk): Don't set TREE_PUBLIC on thunks if the target function is external to the current compilation. gcc/testsuite/ChangeLog: PR d/92216 * gdc.dg/imports/pr92216.d: New. * gdc.dg/pr92216.d: New test.
-
GCC Administrator authored
-
- 17 May, 2020 2 commits
-
-
Iain Buclaw authored
Both array concat and array new expressions wrapped any temporaries created into a BIND_EXPR. This does not work if an expression used to construct the result requires scope destruction, which is represented by a TARGET_EXPR with a clean-up, and a CLEANUP_POINT_EXPR at the location where the temporaries logically go out of scope. The reason for this not working is because the lowering of cleanup point expressions does not traverse inside BIND_EXPRs to expand any gimple cleanup expressions within. The use of creating BIND_EXPR has been removed at both locations, and replaced with a normal temporary variable that has initialization delayed until its address is taken. gcc/d/ChangeLog: PR d/94970 * d-codegen.cc (force_target_expr): Move create_temporary_var implementation inline here. (create_temporary_var): Remove. (maybe_temporary_var): Remove. (bind_expr): Remove. * d-convert.cc (d_array_convert): Use build_local_temp to generate temporaries, and generate its assignment. * d-tree.h (create_temporary_var): Remove. (maybe_temporary_var): Remove. (d_array_convert): Remove vars argument. * expr.cc (ExprVisitor::visit (CatExp *)): Use build_local_temp to generate temporaries, don't wrap them in a BIND_EXPR. (ExprVisitor::visit (NewExp *)): Likewise. gcc/testsuite/ChangeLog: PR d/94970 * gdc.dg/pr94970.d: New test.
-
GCC Administrator authored
-
- 16 May, 2020 3 commits
-
-
Iain Buclaw authored
The Semantic (pass 1) analysis for classes is handled by ClassDeclaration::semantic. For a given class, this method may be ran multiple times in order to resolve forward references. The method incrementally tries to resolve the types referred to by the members of the class. The subsequent calls to this method are short-circuited if the class members have been fully analyzed. For this the code tests that it is not the first/main call to the method (semanticRun == PASS.init else branch), scx is not set, and that the this->symtab is already set. If all these conditions are met, the method returns. But before returning, the method was setting this->semanticRun to PASSsemanticdone. It should not set semanticRun since the class has not been fully analyzed yet. The base class analysis for this class could be pending and as a result vtable may not have been fully created. This fake setting of semanticRun results in the semantic analyzer to believe that the class has been fully analyzed. As exposed by the issues in upstream, it may result in compile time errors when a derived type class is getting analyzed and because of this fake semanticdone on the base class, the semantic analysis construes that an overriden method is not defined in the base class. PR95155 exposes anoter scenario where a buggy vtable may be created and a call to a class method may result in execution of some adhoc code. gcc/d/ChangeLog: PR d/95155 * dmd/dclass.c (ClassDeclaration::semantic): Don't prematurely set done on semantic analysis. gcc/testsuite/ChangeLog: PR d/95155 * gdc.test/compilable/imports/pr9471a.d: New test. * gdc.test/compilable/imports/pr9471b.d: New test. * gdc.test/compilable/imports/pr9471c.d: New test. * gdc.test/compilable/imports/pr9471d.d: New test. * gdc.test/compilable/pr9471.d: New test.
-
Iain Buclaw authored
The last change to the bindings removed the st_pad3 field from the wrong struct. It should have been stat64_t that needed updating instead. libphobos/ChangeLog PR d/90719 * libdruntime/core/sys/posix/sys/stat.d (Solaris): Move st_pad3 from struct stat64_t to stat32_t.
-
GCC Administrator authored
-
- 15 May, 2020 1 commit
-
-
GCC Administrator authored
-
- 14 May, 2020 5 commits
-
-
Szabolcs Nagy authored
It was previously discussed that indirect branches cannot go to NOTE_INSN_DELETED_LABEL so inserting a landing pad is unnecessary. See https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522625.html Before the patch a bti j was inserted after the label in __attribute__((target("branch-protection=bti"))) int foo (void) { label: return 0; } This is not necessary and weakens the security protection. gcc/ChangeLog: Backport from mainline. 2020-04-30 Szabolcs Nagy <szabolcs.nagy@arm.com> PR target/94748 * config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Remove the check for NOTE_INSN_DELETED_LABEL. gcc/testsuite/ChangeLog: Backport from mainline. 2020-04-30 Szabolcs Nagy <szabolcs.nagy@arm.com> PR target/94748 * gcc.target/aarch64/pr94748.c: New test.
-
Szabolcs Nagy authored
The bti pass currently first emits bti c at function start if there is no paciasp (which also acts as indirect call landing pad), then bti j is emitted at jump labels, however if there is a label right before paciasp then the function start can end up like foo: label: bti j paciasp ... This patch is a minimal fix that just moves the bti c handling after the bti j handling so we end up with foo: bti c label: bti j paciasp ... This could be improved by emitting bti jc in this case, or by detecting that the label is not in fact an indirect jump target and then this situation would be much less common. Needs to be backported to gcc-9 branch. Backported without the testcase because of missing infrastructure for check-function-bodies. gcc/ChangeLog: Backport from mainline. 2020-04-23 Szabolcs Nagy <szabolcs.nagy@arm.com> PR target/94697 * config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Swap bti c and bti j handling. -
Szabolcs Nagy authored
On aarch64 -mbranch-protection=pac-ret reuses the dwarf opcode for window_save to mean "toggle the return address mangle state", but in the dwarf2cfi internal logic the state was not updated when an opcode was emitted, the currently present update logic is only valid for the original sparc use of window_save so a separate bool is used on aarch64 to track the state. This bug can cause the unwinder not to authenticate return addresses that were signed (or vice versa) which means a runtime crash on a pauth enabled system. Currently only aarch64 pac-ret uses REG_CFA_TOGGLE_RA_MANGLE. This should be backported to gcc-9 and gcc-8 branches. gcc/ChangeLog: Backport from mainline. 2020-04-27 Szabolcs Nagy <szabolcs.nagy@arm.com> PR target/94515 * dwarf2cfi.c (struct GTY): Add ra_mangled. (cfi_row_equal_p): Check ra_mangled. (dwarf2out_frame_debug_cfa_window_save): Remove the argument, this only handles the sparc logic now. (dwarf2out_frame_debug_cfa_toggle_ra_mangle): New function for the aarch64 specific logic. (dwarf2out_frame_debug): Update to use the new subroutines. (change_cfi_row): Check ra_mangled. gcc/testsuite/ChangeLog: Backport from mainline. 2020-04-27 Szabolcs Nagy <szabolcs.nagy@arm.com> PR target/94515 * g++.target/aarch64/pr94515-1.C: New test. * g++.target/aarch64/pr94515-2.C: New test.
-
Szabolcs Nagy authored
With -mbranch-protection=pac-ret the debug info toggles the signedness state of the return address so the unwinder knows when the return address needs pointer authentication. The unwind context flags were not updated according to the dwarf frame info. This causes unwinding across frames that were built without pac-ret to incorrectly authenticate the return address wich corrupts the return address on a system where PAuth is enabled. Note: This even affects systems where all code use pac-ret because unwinding across a signal frame the return address is not signed. gcc/testsuite/ChangeLog: Backport from mainline. 2020-04-23 Szabolcs Nagy <szabolcs.nagy@arm.com> PR target/94514 * g++.target/aarch64/pr94514.C: Require lp64. * gcc.target/aarch64/pr94514.c: Likewise. Backport from mainline. 2020-04-21 Szabolcs Nagy <szabolcs.nagy@arm.com> PR target/94514 * g++.target/aarch64/pr94514.C: New test. * gcc.target/aarch64/pr94514.c: New test. libgcc/ChangeLog: Backport from mainline. 2020-04-21 Szabolcs Nagy <szabolcs.nagy@arm.com> PR target/94514 * config/aarch64/aarch64-unwind.h (aarch64_frob_update_context): Update context->flags accroding to the frame state.
-
GCC Administrator authored
-
- 13 May, 2020 2 commits
-
-
Mark Eggleston authored
Invalid expressions, such as those involving array constructors, used for the length of character types will cause an ICE. 2020-05-11 Mark Eggleston <markeggleston@gcc.gnu.org> Backported from master 2020-05-13 Steven G. Kargl <kargl@gcc.gnu.org> gcc/fortran/ PR fortran/93497 * decl.c (char_len_param_value): Check whether character length expression is of type EXPR_OP and if so simplify it. * resolve.c (resolve_charlen): Reject length if it has a rank. 2020-05-11 Mark Eggleston <markeggleston@gcc.gnu.org> Backported from master 2020-05-13 Mark Eggleston <markeggleston@gcc.gnu.org> gcc/testsuite/ PR fortran/93497 * gfortran.dg/pr88025.f90: Change in wording of error. * gfortran.dg/pr93497.f90: New test. * gfortran.dg/pr93714_1.f90: Change in wording of errors. * gfortran.dg/pr93714_2.f90: Change in wording of errors.
-
GCC Administrator authored
-
- 12 May, 2020 2 commits
-
-
Jonathan Wakely authored
Calculating the size of a chunk being returned to the upstream allocator was done with a 32-bit type, so it wrapped if the chunk was 4GB or larger. I don't know how to test this without allocating 4GB, so there's no test in the testsuite. It has been tested manually of course. Backport from mainline 2020-05-04 Jonathan Wakely <jwakely@redhat.com> PR libstdc++/94906 * src/c++17/memory_resource.cc (monotonic_buffer_resource::_Chunk::release): Use size_t for shift operands.
-
Clement Chigot authored
AIX applications using 128-bit long double must be linked with libc128.a, in order to have 128-bit compatible routines. AIX 7.2, 7.1, 6.1: Build/Tests: OK 2020-04-03 Clément Chigot <clement.chigot@atos.net> * config/rs6000/aix61.h (LIB_SPEC): Add -lc128 with -mlong-double-128. * config/rs6000/aix71.h (LIB_SPEC): Likewise. * config/rs6000/aix72.h (LIB_SPEC): Likewise.
-