This fixes PR94591. The problem was the function
aarch64_evpc_rev_local() matching vector permutations that were not
reversals. In particular, prior to this patch, this function matched the
identity permutation which led to generating bogus REV64 insns which
were rejected by the assembler.
gcc/
PR target/94591
* config/aarch64/aarch64.c (aarch64_evpc_rev_local): Don't match
identity permutation.
gcc/testsuite/
PR target/94591
* gcc.c-torture/execute/pr94591.c: New test.
Kyrylo Tkachov [Wed, 6 May 2020 15:20:38 +0000 (16:20 +0100)]
[AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc
This version of the fix uses __getauxval instead of getauxval.
The whole thing is guarded simply on __gnu_linux__.
__getauxval was introduced in 2.16 but the aarch64 port was added in 2.17 so in practice I expect all aarch64 glibcs to support __getauxval.
Bootstrapped and tested on aarch64-none-linux-gnu.
Also tested on aarch64-none-elf.
Martin Liska [Fri, 29 May 2020 09:29:25 +0000 (11:29 +0200)]
Fix various limitations of git-backport.py.
I've just tested the script and I'm going to install the patch
to all active branches.
contrib/ChangeLog:
* git-backport.py: The script did 'git co HEAD~' when
there was no modified ChangeLog file in a successful
git cherry pick.
Run cherry-pick --continue without editor.
Based on a patch in the comments of the PR. That patch fixed this
problem but caused the test cases for PR93484 to fail. It has been
changed to reduce initialisation expressions if the expression is
not EXPR_VARIABLE and not EXPR_CONSTANT.
2020-05-28 Steven G. Kargl <kargl@gcc.gnu.org>
Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/fortran/
PR fortran/94397
* match.c (gfc_match_type_spec): New variable ok initialised
to true. Set ok with the return value of gfc_reduce_init_expr
called only if the expression is not EXPR_CONSTANT and is not
EXPR_VARIABLE. Add !ok to the check for type not being integer
or the rank being greater than zero.
2020-05-28 Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/testsuite/
PR fortran/94397
* gfortran.dg/pr94397.F90: New test.
Mark Eggleston [Thu, 7 May 2020 07:15:26 +0000 (08:15 +0100)]
Fortran : ICE in gfc_trans_label_assign PR50392
A function may contain an assigned goto. If the the return variable
is an integer a statement can be assigned to it. Prior to this fix
this resulted in an ICE.
PR fortran/50392
* trans-decl.c (gfc_get_symbol_decl): Remove unnecessary block
delimiters. Add auxiliary variables if a label is assigned to
a return variable. (gfc_gat_fake_result): If the symbol has an
assign attribute set declaration from the symbol's backend
declaration.
2020-05-28 Mark Eggleston <markeggleston@gnu.gcc.org>
gcc/testsuite/
PR fortran/50392
* gfortran.dg/pr50392.f: New test.
PR libfortran/95191
* io/async.c (async_wait_id): Generate error if ID is higher
than the highest current ID.
* runtime/error.c (translate_error): Handle LIBERROR_BAD_WAIT_ID.
libgomp/ChangeLog:
2020-05-23 Thomas Koenig <tkoenig@gcc.gnu.org>
PR libfortran/95191
* testsuite/libgomp.fortran/async_io_9.f90: New test.
Alexandre Oliva [Tue, 26 May 2020 14:28:42 +0000 (11:28 -0300)]
[rs6000] fix mffsl emulation
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.
Jason Merrill [Mon, 25 May 2020 22:38:09 +0000 (18:38 -0400)]
c++: constexpr and lambda capture [PR90212]
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 [Mon, 25 May 2020 22:38:09 +0000 (18:38 -0400)]
c++: Local class DMI using local static [PR90479]
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 [Mon, 25 May 2020 22:38:09 +0000 (18:38 -0400)]
c++: -fmerge-all-constants vs. destructors [PR91529]
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 [Mon, 25 May 2020 22:38:09 +0000 (18:38 -0400)]
c++: generic lambda and -fsanitize=vla-bound [PR93822]
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.
Bin Cheng [Fri, 22 May 2020 03:42:11 +0000 (11:42 +0800)]
Add missing unit dependence vector in data dependence analysis
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.
Mark Eggleston [Thu, 7 May 2020 07:02:02 +0000 (08:02 +0100)]
Fortran : ProcPtr function results: 'ppr@' in error message PR39695
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.
Douglas Rupp [Mon, 18 May 2020 18:43:48 +0000 (11:43 -0700)]
Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c
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.
Iain Buclaw [Sun, 17 May 2020 14:28:24 +0000 (16:28 +0200)]
d: Fix ICE in verify_gimple_stmt, at tree-cfg.c:4959
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.
Iain Buclaw [Sat, 16 May 2020 21:33:15 +0000 (23:33 +0200)]
d: Fix wrong vtable offset in virtual function call
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.
Szabolcs Nagy [Fri, 24 Apr 2020 16:36:02 +0000 (17:36 +0100)]
aarch64: don't emit bti j after NOTE_INSN_DELETED_LABEL [PR94748]
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 [Fri, 17 Apr 2020 15:54:12 +0000 (16:54 +0100)]
aarch64: ensure bti c is emitted at function start [PR94697]
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 [Mon, 27 Apr 2020 08:07:15 +0000 (09:07 +0100)]
aarch64: Fix .cfi_window_save with pac-ret [PR94515]
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 [Fri, 3 Apr 2020 09:35:41 +0000 (09:35 +0000)]
aarch64, libgcc: Fix unwinding from pac-ret to normal frames [PR94514]
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>
Mark Eggleston [Thu, 7 May 2020 07:29:14 +0000 (08:29 +0100)]
Fortran : ICE in gfc_conv_array_constructor_expr PR93497
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.
David Edelsohn [Tue, 12 May 2020 15:46:47 +0000 (11:46 -0400)]
rs6000: AIX long double builtins for 64 bit long double.
When long doubles are 64 bit, the AIX C library overrides the definitions
but GCC builtins point to 128 bit names. This patch overrides the
builtins for fmodl, frexpl, ldexpl and modfl to refer to the 64 bit symbols.
Backport from mainline
2020-05-04 Clement Chigot <clement.chigot@atos.net>
David Edelsohn <dje.gcc@gmail.com>
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Override explicit
for fmodl, frexpl, ldexpl and modfl builtins.
Mark Eggleston [Mon, 11 May 2020 11:38:14 +0000 (12:38 +0100)]
Fortran : Spurious warning message with -Wsurprising PR59107
This change is from a patch developed for gcc-5. The code
has moved on since then requiring a change to interface.c
2020-05-11 Mark Eggleston <markeggleston@gcc.gnu.org>
Backported from mainline
2020-05-11 Janus Weil <janus@gcc.gnu.org>
Dominique d'Humieres <dominiq@lps.ens.fr>
gcc/fortran/
PR fortran/59107
* gfortran.h: Rename field resolved as resolve_symbol_called
and assign two 2 bits instead of 1.
* interface.c (gfc_find_typebound_dtio_proc): Use new field name.
* resolve.c (gfc_resolve_intrinsic): Replace check of the formal
field with resolve_symbol_called is at least 2, if it is not
set the field to 2. (resolve_typebound_procedure): Use new field
name. (resolve_symbol): Use new field name and check whether it
is at least 1, if it is not set the field to 1.
Backported from mainline
2020-05-11 Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/testsuite/
PR fortran/59107
* gfortran.dg/pr59107.f90: New test.
Xionghu Luo [Mon, 11 May 2020 01:27:38 +0000 (20:27 -0500)]
rs6000: Don't use HARD_FRAME_POINTER_REGNUM if it's not live in pro_and_epilogue (PR91518)
Backport from master.
This bug is exposed by FRE refactor of r263875. Comparing the fre
dump file shows no obvious change of the segment fault function proves
it to be a target issue.
frame_pointer_needed is set to true in reload pass setup_can_eliminate,
but regs_ever_live[31] is false, pro_and_epilogue uses it without live
check causing CPU2006 465.tonto segment fault of loading from invalid
addresses due to r31 not saved/restored. Thus, add HARD_FRAME_POINTER_REGNUM
live check with frame_pointer_needed_indeed when generating pro_and_epilogue
instructions.
gcc/ChangeLog
2020-05-11 Xiong Hu Luo <luoxhu@linux.ibm.com>
Backport from master.
2020-04-27 Xiong Hu Luo <luoxhu@linux.ibm.com>
PR target/91518
* config/rs6000/rs6000.c (frame_pointer_needed_indeed):
New variable.
(rs6000_emit_prologue_components):
Check with frame_pointer_needed_indeed.
(rs6000_emit_epilogue_components): Likewise.
(rs6000_emit_prologue): Likewise.
(rs6000_emit_epilogue): Set frame_pointer_needed_indeed.
Uros Bizjak [Thu, 7 May 2020 15:21:15 +0000 (17:21 +0200)]
alpha: Implement the PR94780 fix for alpha.
Essentially the same fix as for x86.
2020-05-07 Uroš Bizjak <ubizjak@gmail.com>
gcc/
* config/alpha/alpha.c (alpha_atomic_assign_expand_fenv): Use
TARGET_EXPR instead of MODIFY_EXPR for the first assignments to
fenv_var and new_fenv_var.
The testcase in the current form doesn't FAIL without the patch on
x86_64-linux unless also testing with -m32; as that the 64-bit testing
on that target is probably way more common, and we can use also attributes
that FAIL without the patch with -m64, the following patch adjusts the
test, so that it FAILs without the patch for both -m64 and -m32 (but not
-mx32) and PASSes with the patch.
2020-05-07 Jakub Jelinek <jakub@redhat.com>
PR c++/94946
* g++.dg/ext/attr-parm-1.C: Enable the test also for lp64 x86, use
sysv_abi and ms_abi attributes in that case instead of fastcall and
no attribute.
Rainer Orth [Thu, 7 May 2020 07:41:21 +0000 (09:41 +0200)]
libstdc++: Update Solaris baselines for GCC 9.4
Just as for GCC 10.1, the libstdc++ ABI baselines need to be regenerated on
the gcc-9 branch for the GLIBCXX_3.4.28 symbols added in GCC 9.3.0. The
following patch does that for Solaris.
Tested on i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01].
Jakub Jelinek [Wed, 6 May 2020 09:21:28 +0000 (11:21 +0200)]
libstdc++: Update {x86_64,i?86,powerpc64,s390x,aarch64}-linux baselines for GCC 10.1
On Wed, May 06, 2020 at 10:49:13AM +0200, Rainer Orth wrote:
> I just remembered that the libstdc++ ABI baselines haven't been updated
> for the GCC 10 release yet. This patch corrects this for Solaris/SPARC
> and x86.
Oops, here are the updates from Fedora packages built during the weekend.
Andreas Krebbel [Tue, 5 May 2020 08:46:33 +0000 (10:46 +0200)]
IBM Z: vec_store_len_r/vec_load_len_r fix
This fixes a problem with the vec_store_len_r intrinsic. The macros
mapping the intrinsic to a GCC builtin had the wrong signature.
With the patch an immediate length operand of vlrl/vstrl is handled
the same way as if it was passed in a register to vlrlr/vstrlr.
Values bigger than 15 always load the full vector. If it can be
recognized that it is in effect a full vector register load or store
it is now implemented with vl/vst instead.
gcc/ChangeLog:
2020-05-05 Andreas Krebbel <krebbel@linux.ibm.com>
Backport from mainline
2020-04-30 Andreas Krebbel <krebbel@linux.ibm.com>
* config/s390/constraints.md ("j>f", "jb4"): New constraints.
* config/s390/vecintrin.h (vec_load_len_r, vec_store_len_r): Fix
macro definitions.
* config/s390/vx-builtins.md ("vlrlrv16qi", "vstrlrv16qi"): Add a
separate expander.
("*vlrlrv16qi", "*vstrlrv16qi"): Add alternative for vl/vst.
Change constraint for vlrl/vstrl to jb4.
gcc/testsuite/ChangeLog:
2020-05-05 Andreas Krebbel <krebbel@linux.ibm.com>
Backport from mainline
2020-04-30 Andreas Krebbel <krebbel@linux.ibm.com>
* gcc.target/s390/zvector/vec_load_len_r.c: New test.
* gcc.target/s390/zvector/vec_store_len_r.c: New test.
Jonathan Wakely [Mon, 4 May 2020 21:54:25 +0000 (22:54 +0100)]
libstdc++: Fix broken link to SGI STL FAQ
The previous URL to an entry in the wayback machine now redirects to a
page saying "SGI.com Tech Archive Resources now retired" so use an older
entry from the archive.
* doc/xml/faq.xml: Use working link for SGI STL FAQ.
* doc/html/*: Regenerate.
Tobias Burnus [Mon, 4 May 2020 11:47:41 +0000 (13:47 +0200)]
ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951
gcc/testsuite/
Backport from mainline.
2020-03-08 Paul Thomas <pault@gcc.gnu.org>
PR fortran/93581
* resolve.c (gfc_resolve_ref): Modify array refs to be elements
if the ref chain ends in INQUIRY_LEN.
* trans-array.c (gfc_get_dataptr_offset): Provide the offsets
for INQUIRY_RE and INQUIRY_IM.
gcc/testsuite/
Backport from mainline.
2020-03-08 Paul Thomas <pault@gcc.gnu.org>
PR fortran/93581
* gfortran.dg/inquiry_type_ref_6.f90 : New test.
Andreas Krebbel [Mon, 20 Apr 2020 18:06:53 +0000 (20:06 +0200)]
S/390: Fix PR94666
The vector popcount expanders use a hardcoded subreg. This might lead
to double subregs being generated which then fail to match. With this
patch simplify_gen_subreg is used instead to fold the subregs.
gcc/ChangeLog:
2020-05-04 Andreas Krebbel <krebbel@linux.ibm.com>
Backport from mainline
2020-04-20 Andreas Krebbel <krebbel@linux.ibm.com>
* config/s390/vector.md ("popcountv8hi2_vx", "popcountv4si2_vx")
("popcountv2di2_vx"): Use simplify_gen_subreg.
gcc/testsuite/ChangeLog:
2020-05-04 Andreas Krebbel <krebbel@linux.ibm.com>
Backport from mainline
2020-04-20 Andreas Krebbel <krebbel@linux.ibm.com>
Andreas Krebbel [Mon, 20 Apr 2020 17:36:33 +0000 (19:36 +0200)]
PR94613: Fix vec_sel builtin for IBM Z
The vsel instruction is a bit-wise select instruction. Using an
IF_THEN_ELSE to express it in RTL is wrong and leads to wrong code being
generated in the combine pass.
With the patch the pattern is written using bit operations. However,
I've just noticed that the manual still demands a fixed point mode for
AND/IOR and friends although several targets emit bit ops on floating
point vectors (including i386, Power, and s390). So I assume this is a
safe thing to do?!
gcc/ChangeLog:
2020-05-04 Andreas Krebbel <krebbel@linux.ibm.com>
Backport from mainline
2020-04-20 Andreas Krebbel <krebbel@linux.ibm.com>
PR target/94613
* config/s390/s390-builtin-types.def: Add 3 new function modes.
* config/s390/s390-builtins.def: Add mode dependent low-level
builtin and map the overloaded builtins to these.
* config/s390/vx-builtins.md ("vec_selV_HW"): Rename to ...
("vsel<V_HW"): ... this and rewrite the pattern with bitops.
gcc/testsuite/ChangeLog:
2020-05-04 Andreas Krebbel <krebbel@linux.ibm.com>
Backport from mainline
2020-04-20 Andreas Krebbel <krebbel@linux.ibm.com>
PR target/94613
* gcc.target/s390/zvector/pr94613.c: New test.
* gcc.target/s390/zvector/vec_sel-1.c: New test.
Bin Cheng [Mon, 4 May 2020 06:28:54 +0000 (14:28 +0800)]
Add unsigned type iv_cand for iv_use with non mode-precision type
Precisely, for iv_use if it's not integer/pointer type, or non-mode
precision type, add candidate for the corresponding scev in unsigned
type with the same precision, rather than its original type.
Backport from master.
2020-04-09 Bin Cheng <bin.cheng@linux.alibaba.com>
PR tree-optimization/93674
gcc/
* tree-ssa-loop-ivopts.c (langhooks.h): New include.
(add_iv_candidate_for_use): For iv_use of non integer or pointer type,
or non-mode precision type, add candidate in unsigned type with the
same precision.
H.J. Lu [Wed, 29 Apr 2020 11:52:46 +0000 (04:52 -0700)]
x86: Allow -fcf-protection with external thunk
Allow -fcf-protection with external thunk since the external thunk can be
made compatible with -fcf-protection.
gcc/
Backport from master
PR target/93654
* config/i386/i386-options.c (ix86_set_indirect_branch_type):
Allow -fcf-protection with -mindirect-branch=thunk-extern and
-mfunction-return=thunk-extern.
* doc/invoke.texi: Update notes for -fcf-protection=branch with
-mindirect-branch=thunk-extern and -mindirect-return=thunk-extern.
gcc/testsuite/
Backport from master
PR target/93654
* gcc.target/i386/pr93654.c: New test.
Jason Merrill [Mon, 27 Jan 2020 10:45:01 +0000 (05:45 -0500)]
c++: Avoid ICE with dependent attribute on type.
We previously happened to accept this testcase, but never actually did
anything useful with the attribute. The patch for PR86379 stopped using
TREE_TYPE as USING_DECL_SCOPE, so 'using A::b' no longer had TREE_TYPE set,
so the language-independent decl_attributes started crashing on it.
GNU attributes are more flexible in their placement than C++11 attributes,
so if we encounter a dependent GNU attribute that syntactically appertains
to a type rather than the declaration as a whole, move it to the
declaration; that's almost certainly what the user meant, anyway.
gcc/cp/ChangeLog
2020-01-27 Jason Merrill <jason@redhat.com>
PR c++/90750
PR c++/79585
* decl.c (grokdeclarator): Move dependent attribute to decl.
* decl2.c (splice_template_attributes): No longer static.
projects / thirdparty / gcc.git / log
