Releases/gcc 12 #65
Open
Releases/gcc 12 #65
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This is an unofficial mirror that has nothing to do with the GCC project, so submitting pull requests here is a waste of time. Also, I have no idea what this pull request is trying to do but it would never be accepted even if it was submitted to the right place. |
atahanozbayram
approved these changes
Apr 2, 2024
Although for instructions MVI and MVIY it does not make a difference whether the immediate is interpreted as signed or unsigned, GAS expects unsigned immediates for instruction format SI_URD. gcc/ChangeLog: * config/s390/vector.md (mov<mode>): Fix output template for movv1qi. (cherry picked from commit e6680d3)
Add missing "cannot_copy" attribute to instructions that have to stay in 1-1 correspondence with another insn. PR target/115526 gcc/ChangeLog: * config/alpha/alpha.md (movdi_er_high_g): Add cannot_copy attribute. (movdi_er_tlsgd): Ditto. (movdi_er_tlsldm): Ditto. (call_value_osf_<tls>): Ditto. gcc/testsuite/ChangeLog: * gcc.target/alpha/pr115526.c: New test. (cherry picked from commit 0841fd4)
A reference to a COMDAT function may be resolved to another definition outside the current translation unit, so it's not eligible for `-fipa-ra`. In `decl_binds_to_current_def_p()` there is already a check for weak symbols. This commit checks for COMDAT functions that are not implemented as weak symbols, for example, on *-*-mingw32. gcc/ChangeLog: PR rtl-optimization/115049 * varasm.cc (decl_binds_to_current_def_p): Add a check for COMDAT declarations too, like weak ones. (cherry picked from commit 5080840)
Code attribute bhfgq is missing a mapping for TF. This results in unresolved iterators in assembler templates for *bswaptf. With the TF mapping added the base mnemonics vlbr and vstbr are not "used" anymore but only the extended mnemonics (vlbr<bhfgq> was interpreted as vlbr; likewise for vstbr). Therefore, remove the base mnemonics from the scheduling description, otherwise, genattrtab would error about unknown mnemonics. Likewise, for movtf_vr only the extended mnemonics for vrepi are used, now, which means the base mnemonic is "unused" and has to be removed from the scheduling description. Similarly, we end up with unresolved iterators in assembler templates for mulfprx23 since code attribute xdee is missing a mapping for FPRX2. Note, this is basically a cherry pick of commit r15-2060-ga4abda934aa426 with the addition that vrepi is removed from the scheduling description, too. gcc/ChangeLog: * config/s390/3931.md (vlbr, vstbr, vrepi): Remove. * config/s390/s390.md (xdee): Add FPRX2 mapping. * config/s390/vector.md (bhfgq): Add TF mapping.
There are various non-IBM CPUs with altivec, so we cannot use that flag to determine which .machine cpu to use, so ignore it. Emit an additional ".machine altivec" if Altivec is enabled so that the assembler doesn't require an explicit -maltivec option to assemble any Altivec instructions for those targets where the ".machine cpu" is insufficient to enable Altivec. For example, -mcpu=G5 emits a ".machine power4". 2024-07-18 René Rebe <rene@exactcode.de> Peter Bergner <bergner@linux.ibm.com> gcc/ PR target/97367 * config/rs6000/rs6000.cc (rs6000_machine_from_flags): Do not consider OPTION_MASK_ALTIVEC. (emit_asm_machine): For Altivec compiles, emit a ".machine altivec". gcc/testsuite/ PR target/97367 * gcc.target/powerpc/pr97367.c: New test. Signed-off-by: René Rebe <rene@exactcode.de> (cherry picked from commit 6962835)
The inner loop in build_option_suggestions uses OPTION to take the address of OPTB and use it across iterations, which is undefined behaviour since OPTB is defined within the loop. Pull it outside the loop to make this defined. gcc/ChangeLog: * opt-suggestions.cc (option_proposer::build_option_suggestions): Pull OPTB definition out of the innermost loop. (cherry picked from commit e0d997e)
…03115] gcc/fortran/ChangeLog: PR fortran/103115 * trans-array.cc (gfc_trans_array_constructor_value): If the first element of an array constructor is deferred-length character and therefore does not have an element size known at compile time, do not try to collect subsequent constant elements into a constructor for optimization. gcc/testsuite/ChangeLog: PR fortran/103115 * gfortran.dg/string_array_constructor_4.f90: New test. (cherry picked from commit c93be16)
…n_qty Use INT_MIN rather than -1 in `comparison_qty' where a comparison is not with a register, because the value of -1 is actually a valid reference to register 0 in the case where it has not been assigned a quantity. Using -1 makes `REG_QTY (REGNO (folded_arg1)) == ent->comparison_qty' comparison in `fold_rtx' to incorrectly trigger in rare circumstances and return true for a memory reference, making CSE consider a comparison operation to evaluate to a constant expression and consequently make the resulting code incorrectly execute or fail to execute conditional blocks. This has caused a miscompilation of rwlock.c from LinuxThreads for the `alpha-linux-gnu' target, where `rwlock->__rw_writer != thread_self ()' expression (where `thread_self' returns the thread pointer via a PALcode call) has been decided to be always true (with `ent->comparison_qty' using -1 for a reference to to `rwlock->__rw_writer', while register 0 holding the thread pointer retrieved by `thread_self') and code for the false case has been optimized away where it mustn't have, causing program lockups. The issue has been observed as a regression from commit 08a6926 ("Undefined cse.c behaviour causes 3.4 regression on HPUX"), <https://gcc.gnu.org/ml/gcc-patches/2004-10/msg02027.html>, and up to commit 932ad4d ("Make CSE path following use the CFG"), <https://gcc.gnu.org/ml/gcc-patches/2006-12/msg00431.html>, where CSE has been restructured sufficiently for the issue not to trigger with the original reproducer anymore. However the original bug remains and can trigger, because `comparison_qty' will still be assigned -1 for a memory reference and the `reg_qty' member of a `cse_reg_info_table' entry will still be assigned -1 for register 0 where the entry has not been assigned a quantity, e.g. at initialization. Use INT_MIN then as noted above, so that the value remains negative, for consistency with the REGNO_QTY_VALID_P macro (even though not used on `comparison_qty'), and then so that it should not ever match a valid negated register number, fixing the regression with commit 08a6926. gcc/ PR rtl-optimization/115565 * cse.cc (record_jump_cond): Use INT_MIN rather than -1 for `comparison_qty' if !REG_P. (cherry picked from commit 69bc5fb)
The dg-do directive appears after dg-require-effective-target in g++.target/powerpc/pr106069.C. That doesn't work the way that was presumably intended. Both of these directives set dg-do-what, but dg-do does so fully and unconditionally, overriding any decisions recorded there by earlier directives. Reorder the directives more canonically, so that both take effect. for gcc/testsuite/ChangeLog PR target/106069 * g++.target/powerpc/pr106069.C: Reorder dg directives. (cherry picked from commit ad65caa)
Currently unaligned YMM and ZMM load and store costs are cheaper than aligned which causes the vectorizer to purposely mis-align accesses by adding an alignment prologue. It looks like the unaligned costs were simply left untouched from znver3 where they equate the aligned costs when tweaking aligned costs for znver4. The following makes the unaligned costs equal to the aligned costs. This avoids the miscompile seen in PR115843 but it's of course not a real fix for the issue uncovered there. But it makes it qualify as a regression fix. PR tree-optimization/115843 * config/i386/x86-tune-costs.h (znver4_cost): Update unaligned load and store cost from the aligned costs. (cherry picked from commit 1e3aa9c)
… location The ELFv2 stack frame layout comment in rs6000-logue.cc shows the ROP hash save slot in the wrong location. Update the comment to show the correct ROP hash save location in the frame. 2024-06-07 Peter Bergner <bergner@linux.ibm.com> gcc/ * config/rs6000/rs6000-logue.cc (rs6000_stack_info): Update comment. (cherry picked from commit e91cf26)
We currently only compute the offset for the ROP hash save location in the stack frame for Altivec compiles. For non-Altivec compiles when we emit ROP mitigation instructions, we use a default offset of zero which corresponds to the backchain save location which will get clobbered on any call. The fix is to compute the ROP hash save location for all compiles. 2024-06-14 Peter Bergner <bergner@linux.ibm.com> gcc/ PR target/115389 * config/rs6000/rs6000-logue.cc (rs6000_stack_info): Compute rop_hash_save_offset for non-Altivec compiles. gcc/testsuite PR target/115389 * gcc.target/powerpc/pr115389.c: New test. (cherry picked from commit c70eea0)
…4759] We currently only emit the ROP-protect hash* insns for Power10, where the insns were added to the architecture. We want to emit them for earlier cpus (where they operate as NOPs), so that if those older binaries are ever executed on a Power10, then they'll be protected from ROP attacks. Binutils accepts hashst and hashchk back to Power8, so change GCC to emit them for Power8 and later. This matches clang's behavior. 2024-06-19 Peter Bergner <bergner@linux.ibm.com> gcc/ PR target/114759 * config/rs6000/rs6000-logue.cc (rs6000_stack_info): Use TARGET_POWER8. (rs6000_emit_prologue): Likewise. * config/rs6000/rs6000.md (hashchk): Likewise. (hashst): Likewise. Fix whitespace. gcc/testsuite/ PR target/114759 * gcc.target/powerpc/pr114759-2.c: New test. * lib/target-supports.exp (rop_ok): Use check_effective_target_has_arch_pwr8. (cherry picked from commit a05c3d2)
…insns [PR114759] We currently silently ignore the -mrop-protect option for old CPUs we don't support with the ROP hash insns, but we throw an error for unsupported ABIs. This patch treats unsupported CPUs and ABIs similarly by throwing an error both both. This matches clang behavior and allows us to simplify our tests in the code that generates our prologue and epilogue code. 2024-06-26 Peter Bergner <bergner@linux.ibm.com> gcc/ PR target/114759 * config/rs6000/rs6000.cc (rs6000_option_override_internal): Disallow CPUs and ABIs that do no support the ROP protection insns. * config/rs6000/rs6000-logue.cc (rs6000_stack_info): Remove now unneeded tests. (rs6000_emit_prologue): Likewise. Remove unneeded gcc_assert. (rs6000_emit_epilogue): Likewise. * config/rs6000/rs6000.md: Likewise. gcc/testsuite/ PR target/114759 * gcc.target/powerpc/pr114759-3.c: New test. (cherry picked from commit 6f2bab9)
…59,PR115988] 2024-07-18 Peter Bergner <bergner@linux.ibm.com> gcc/testsuite/ PR target/114759 PR target/115988 * gcc.target/powerpc/pr114759-3.c: Catch unsupported ABI errors. (cherry picked from commit b2f47a5)
2024-11-14 Paul Thomas <pault@gcc.gnu.org> gcc/fortran PR fortran/105054 * resolve.cc (get_temp_from_expr): If the pointer function has a deferred character length, generate a new deferred charlen for the temporary. gcc/testsuite/ PR fortran/105054 * gfortran.dg/ptr_func_assign_6.f08: New test. (cherry picked from commit f530a8c)
Add missing Runtime Library Exception to mve header files to bring them into line with other similar headers. Not adding it in the first place was an oversight. gcc/ChangeLog: * config/arm/arm_mve.h: Add Runtime Library Exception. * config/arm/arm_mve_types.h: Likewise. (cherry picked from commit cde7ce0)
…n [PR117615]
We currently reject the following valid code:
=== cut here ===
struct Base {
virtual void doit (int v) const {}
};
struct Derived : Base {
void doit (int v) const {}
};
using fn_t = void (Base::*)(int) const;
struct Helper {
fn_t mFn;
constexpr Helper (auto && fn) : mFn(static_cast<fn_t>(fn)) {}
};
void foo () {
constexpr Helper h (&Derived::doit);
}
=== cut here ===
The problem is that since r6-4014-gdcdbc004d531b4, &Derived::doit is
represented with an expression with type pointer to method and using an
INTEGER_CST (here 1), and that cxx_eval_constant_expression rejects any
such expression with a non-null INTEGER_CST.
This patch uses the same strategy as r12-4491-gf45610a45236e9 (fix for
PR c++/102786), and simply lets such expressions go through.
PR c++/117615
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression): Don't reject
INTEGER_CSTs with type POINTER_TYPE to METHOD_TYPE.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/constexpr-virtual22.C: New test.
(cherry picked from commit 72a2380)
In nonlocal_goto sets, change hard_frame_pointer_rtx only after emit_stack_restore() restored SP. This is needed because SP my be stored in some frame location. gcc/ PR target/64242 * config/avr/avr.md (nonlocal_goto): Don't restore hard_frame_pointer_rtx directly, but copy it to local register, and only set hard_frame_pointer_rtx from it after emit_stack_restore(). (cherry picked from commit f7b5527)
…alues This fixes a precondition failure triggered when the Eigenvalues routine of Ada.Numerics.Generic_Real_Arrays is instantiated with -gnata, beause it calls Sort_Eigensystem on an empty vector. gcc/ada PR ada/117996 * libgnat/a-ngrear.adb (Jacobi): Remove default value for Compute_Vectors formal parameter. (Sort_Eigensystem): Add Compute_Vectors formal parameter. Do not modify the Vectors if Compute_Vectors is False. (Eigensystem): Pass True as Compute_Vectors to Sort_Eigensystem. (Eigenvalues): Pass False as Compute_Vectors to Sort_Eigensystem. gcc/testsuite * gnat.dg/matrix1.adb: New test.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Support for Apple Silicon!!!