Similarly to other recently-added autovectorization patterns, mult has
been erroneously enabled for iwmmxt. However, V4HI and V2SI modes are
supported, so we make an exception for them.
The new testcase is derived from gcc.dg/ubsan/pr79904.c, with
additional modes added.
I kept dg-do compile because 'assemble' results in error messages from
the assembler, which are not related to this PR:
Error: selected processor does not support `tmcrr wr0,r4,r5' in ARM mode
Error: selected processor does not support `wstrd wr0,[r0]' in ARM mode
Error: selected processor does not support `wldrd wr0,[r0]' in ARM mode
Error: selected processor does not support `wldrd wr2,.L5' in ARM mode
Error: selected processor does not support `wmulul wr0,wr0,wr2' in ARM mode
Error: selected processor does not support `wstrd wr0,[r0]' in ARM mode
Error: selected processor does not support `wldrd wr0,[r0]' in ARM mode
Error: selected processor does not support `wldrd wr2,.L8' in ARM mode
Error: selected processor does not support `wmulwl wr0,wr0,wr2' in ARM mode
Error: selected processor does not support `wstrd wr0,[r0]' in ARM mode
2021-03-29 Christophe Lyon <christophe.lyon@linaro.org>
PR target/99786
gcc/
* config/arm/vec-common.md (mul<mode>3): Disable on iwMMXT, expect
for V4HI and V2SI.
gcc/testsuite/
* gcc.target/arm/pr99786.c: New test.
Simply memcpy and memset inline strategies to avoid branches for
-mtune=icelake:
1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
load and store for up to 16 * 16 (256) bytes when the data size is
fixed and known.
2. Inline only if data size is known to be <= 256.
a. Use "rep movsb/stosb" with simple code sequence if the data size
is a constant.
b. Use loop if data size is not a constant.
3. Use memcpy/memset libray function if data size is unknown or > 256.
On Ice Lake processor with -march=native -Ofast -flto,
1. Performance impacts of SPEC CPU 2017 rate are:
500.perlbench_r -0.93%
502.gcc_r 0.36%
505.mcf_r 0.31%
520.omnetpp_r -0.07%
523.xalancbmk_r -0.53%
525.x264_r -0.09%
531.deepsjeng_r -0.19%
541.leela_r 0.16%
548.exchange2_r 0.22%
557.xz_r -1.64%
Geomean -0.24%
503.bwaves_r -0.01%
507.cactuBSSN_r 0.00%
508.namd_r 0.12%
510.parest_r 0.07%
511.povray_r 0.29%
519.lbm_r 0.00%
521.wrf_r -0.38%
526.blender_r 0.16%
527.cam4_r 0.18%
538.imagick_r 0.76%
544.nab_r -0.84%
549.fotonik3d_r -0.07%
554.roms_r -0.01%
Geomean 0.02%
2. Significant impacts on eembc benchmarks are:
eembc/nnet_test 9.90%
eembc/mp2decoddata2 16.42%
eembc/textv2data3 -4.86%
eembc/qos 12.90%
gcc/
* config/i386/i386-expand.c (expand_set_or_cpymem_via_rep):
For TARGET_PREFER_KNOWN_REP_MOVSB_STOSB, don't convert QImode
to SImode.
(decide_alg): For TARGET_PREFER_KNOWN_REP_MOVSB_STOSB, use
"rep movsb/stosb" only for known sizes.
* config/i386/i386-options.c (processor_cost_table): Use Ice
Lake cost for Cannon Lake, Ice Lake, Tiger Lake, Sapphire
Rapids and Alder Lake.
* config/i386/i386.h (TARGET_PREFER_KNOWN_REP_MOVSB_STOSB): New.
* config/i386/x86-tune-costs.h (icelake_memcpy): New.
(icelake_memset): Likewise.
(icelake_cost): Likewise.
* config/i386/x86-tune.def (X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB):
New.
gcc/testsuite/
* gcc.target/i386/memcpy-strategy-5.c: New test.
* gcc.target/i386/memcpy-strategy-6.c: Likewise.
* gcc.target/i386/memcpy-strategy-7.c: Likewise.
* gcc.target/i386/memcpy-strategy-8.c: Likewise.
* gcc.target/i386/memset-strategy-3.c: Likewise.
* gcc.target/i386/memset-strategy-4.c: Likewise.
* gcc.target/i386/memset-strategy-5.c: Likewise.
* gcc.target/i386/memset-strategy-6.c: Likewise.
The vectoriser supports peeling for alignment using predication:
we move back to the previous aligned boundary and make the skipped
elements inactive in the first loop iteration. As it happens,
the costs for existing CPUs give an equal cost to aligned and
unaligned accesses, so this feature is rarely used.
However, the PR shows that when the feature was forced on, we were
still trying to align to a full-vector boundary even when using
partial vectors.
gcc/
PR target/98119
* config/aarch64/aarch64.c
(aarch64_vectorize_preferred_vector_alignment): Query the size
of the provided SVE vector; do not assume that all SVE vectors
have the same size.
gcc/testsuite/
PR target/98119
* gcc.target/aarch64/sve/pr98119.c: New test.
PR lto/99447
* cgraph.c (cgraph_node::release_body): Remove all callers and
references.
* cgraphclones.c (cgraph_node::materialize_clone): Do not do it here.
* cgraphunit.c (cgraph_node::expand): And here.
As mentioned in the PR, Uai constraint stands for
aarch64_sve_scalar_inc_dec_immediate
while Uav for
aarch64_sve_addvl_addpl_immediate.
Both *add<mode>3_aarch64 and *add<mode>3_poly_1 patterns use
* return aarch64_output_sve_scalar_inc_dec (operands[2]);
* return aarch64_output_sve_addvl_addpl (operands[2]);
in that order, but the former with Uai,Uav order, while the
latter with Uav,Uai instead. This patch swaps the constraints
so that they match the output.
Co-authored-by: Richard Sandiford <richard.sandiford@arm.com>
2021-03-31 Jakub Jelinek <jakub@redhat.com>
Richard Sandiford <richard.sandiford@arm.com>
PR target/99813
* config/aarch64/aarch64.md (*add<mode>3_poly_1): Swap Uai and Uav
constraints on operands[2] and similarly 0 and rk constraints
on operands[1] corresponding to that.
* g++.target/aarch64/sve/pr99813.C: New test.
As mentioned in the PR, before the
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0
fix from March 1st, PECOFF ld.bfd didn't know about .debug_loclists,
.debug_rnglists and other debug sections new in DWARF 5. Unfortunately,
unlike for ELF linkers, that means the sections were placed in wrong
ordering with wrong VMA/LMA, so the resulting executables are apparently
unusable.
As that is pretty new change, newer than 2.35.2 or 2.36 binutils releases,
the following patch adds a workaround that turns -gdwarf-4 by default
instead of -gdwarf-5 if a broken linker is found at configure time.
Users can still explicitly play with -gdwarf-5 and either use a non-broken
linker or use custom linker scripts for the broken one, but at least
by default it should work.
2021-03-31 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/98860
* configure.ac (HAVE_LD_BROKEN_PE_DWARF5): New AC_DEFINE if PECOFF
linker doesn't support DWARF sections new in DWARF5.
* config/i386/i386-options.c (ix86_option_override_internal): Default
to dwarf_version 4 if HAVE_LD_BROKEN_PE_DWARF5 for TARGET_PECOFF
targets.
* config.in: Regenerated.
* configure: Regenerated.
Seems the target hook is only defined on
config/i386/i386.c:#undef TARGET_ZERO_CALL_USED_REGS
config/i386/i386.c:#define TARGET_ZERO_CALL_USED_REGS ix86_zero_call_used_regs
config/sparc/sparc.c:#undef TARGET_ZERO_CALL_USED_REGS
config/sparc/sparc.c:#define TARGET_ZERO_CALL_USED_REGS sparc_zero_call_used_regs
but apparently many of the tests actually succeed on various targets that
don't define those hooks. E.g. I haven't seen them to fail on aarch64,
on arm only the -10.c fails, on powerpc*/s390* all {8,9,10,11} fail (plus
5 is skipped on power*-aix*).
On ia64 according to testresults {6,7,8,9,10,11} fail, some with ICEs.
On mipsel according to testresults {9,10,11} fail, some with ICEs.
On nvptx at least 1-9 succeed, 10-11 don't know, don't have assert.h around.
I've kept {5,6,7} with aix,ia64,ia64 skipped because those seems like
outliers, it works pretty much everywhere but on those.
The rest have known good targets.
2021-03-31 Jakub Jelinek <jakub@redhat.com>
PR testsuite/97680
* c-c++-common/zero-scratch-regs-6.c: Skip on ia64.
* c-c++-common/zero-scratch-regs-7.c: Likewise.
* c-c++-common/zero-scratch-regs-8.c: Change from dg-skip-if of
selected unsupported triplets to all targets but selected triplets
of supported targets.
* c-c++-common/zero-scratch-regs-9.c: Likewise.
* c-c++-common/zero-scratch-regs-10.c: Likewise.
* c-c++-common/zero-scratch-regs-11.c: Likewise.
r11-4926 made __alignof__ get mangled differently from alignof,
encoding __alignof__ as a vendor extended operator. But this
mangling is problematic for the reasons mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115#c6.
This patch changes our mangling of __alignof__ to instead use the
new "vendor extended expression" syntax that's proposed in
https://github.com/itanium-cxx-abi/cxx-abi/issues/112. Clang does
the same thing already, so after this patch Clang and GCC agree
about the mangling of __alignof__(type) and __alignof__(expr).
gcc/cp/ChangeLog:
PR c++/88115
* mangle.c (write_expression): Adjust the mangling of
__alignof__.
include/ChangeLog:
PR c++/88115
* demangle.h (enum demangle_component_type): Add
DEMANGLE_COMPONENT_VENDOR_EXPR.
libiberty/ChangeLog:
PR c++/88115
* cp-demangle.c (d_dump, d_make_comp, d_expression_1)
(d_count_templates_scopes): Handle DEMANGLE_COMPONENT_VENDOR_EXPR.
(d_print_comp_inner): Likewise.
<case DEMANGLE_COMPONENT_EXTENDED_OPERATOR>: Revert r11-4926
change.
<case DEMANGLE_COMPONENT_UNARY>: Likewise.
* testsuite/demangle-expected: Adjust __alignof__ tests.
gcc/testsuite/ChangeLog:
PR c++/88115
* g++.dg/cpp0x/alignof7.C: Adjust expected mangling.
When checking dependence of a placeholder type constraint, if the first
template argument of the constraint is an argument pack, we need to
expand it in order to properly separate the implicit 'auto' argument
from the rest.
gcc/cp/ChangeLog:
PR c++/99815
* pt.c (placeholder_type_constraint_dependent_p): Expand
argument packs to separate the first non-pack argument
from the rest.
gcc/testsuite/ChangeLog:
PR c++/99815
* g++.dg/cpp2a/concepts-placeholder5.C: New test.
impl_sm_context::get_diagnostic_tree could be expensive, and
I find myself needing to put a breakpoint on it to debug
PR analyzer/99771, so only call it if we're about to use
the result.
gcc/analyzer/ChangeLog:
* sm-file.cc (fileptr_state_machine::on_stmt): Only call
get_diagnostic_tree if the result will be used.
* sm-malloc.cc (malloc_state_machine::on_stmt): Likewise.
(malloc_state_machine::on_deallocator_call): Likewise.
(malloc_state_machine::on_realloc_call): Likewise.
(malloc_state_machine::on_realloc_call): Likewise.
* sm-sensitive.cc
(sensitive_state_machine::warn_for_any_exposure): Likewise.
* sm-taint.cc (taint_state_machine::on_stmt): Likewise.
This is the bug that keeps on giving. Reducing it has been successful
at hitting other defects. In this case, some more specialization hash
table fun, plus an issue with reading in a definition of a duplicated
declaration. At least I discovered a null context check is no longer
needed.
PR c++/99283
gcc/cp/
* module.cc (dumper::operator): Make less brittle.
(trees_out::core_bools): VAR_DECLs always have a context.
(trees_out::key_mergeable): Use same_type_p for asserting.
(trees_in::read_var_def): Propagate
DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P.
gcc/testsuite/
* g++.dg/modules/pr99283-5.h: New.
* g++.dg/modules/pr99283-5_a.H: New.
* g++.dg/modules/pr99283-5_b.H: New.
* g++.dg/modules/pr99283-5_c.C: New.
The following testcase ICEs (since the addition of inline var support),
because the lambda contains PTRMEM_CST but finish_function is called for the
lambda quite early during parsing it (from finish_lambda_function) when
the containing class is still incomplete. That means that during
genericization cplus_expand_constant keeps the PTRMEM_CST unmodified, but
later nothing lowers it when the class is finalized.
Using sizeof etc. on the class in such contexts is rejected by both g++ and
clang++, and when the PTRMEM_CST appears e.g. in static var initializers
rather than in functions, we handle it correctly because c_parse_final_cleanups
-> lower_var_init will handle those cplus_expand_constant when all classes
are already finalized.
The following patch fixes it by calling cplus_expand_constant again during
gimplification, as we are now unconditionally unit at a time, I'd think
everything that could be completed will be before we start gimplification.
2021-03-30 Jakub Jelinek <jakub@redhat.com>
PR c++/99790
* cp-gimplify.c (cp_gimplify_expr): Handle PTRMEM_CST.
* g++.dg/cpp1z/pr99790.C: New test.
This fixes a simple segfault ICE when using the use_new_vector_costs tunable with a CPU tuning that it wasn't intended for.
I'm not adding a testcase here as we intend to remove the tunable for GCC 12 anyway (the new costing logic will remain and will benefit
from this extra check, but the -moverride option will no longer exist).
gcc/ChangeLog:
PR target/99820
* config/aarch64/aarch64.c (aarch64_analyze_loop_vinfo): Check for
available issue_info before using it.
In this PR we end up generating an invalid instruction:
adds x1,xzr,#2
because the pattern accepts zero as an operand in the comparison, but the instruction doesn't.
Fix it by adjusting the predicate and constraints.
gcc/ChangeLog:
PR target/99822
* config/aarch64/aarch64.md (sub<mode>3_compare1_imm): Do not allow zero
in operand 1.
gcc/testsuite/ChangeLog:
PR target/99822
* gcc.c-torture/compile/pr99822.c: New test.
Define __rdtsc and __rdtscp as macros for callers with general-regs-only
target attribute to avoid inline failure with always_inline attribute.
gcc/
PR target/99744
* config/i386/ia32intrin.h (__rdtsc): Defined as macro.
(__rdtscp): Likewise.
gcc/testsuite/
PR target/99744
* gcc.target/i386/pr99744-1.c: New test.
TWO_OPERANDS allows any order or number of combinations of + and - operations
but the pattern matcher only supports pairs of operations.
This patch has the pattern matcher for complex numbers reject SLP trees where
the lanes are not a multiple of 2.
gcc/ChangeLog:
PR tree-optimization/99825
* tree-vect-slp-patterns.c (vect_check_evenodd_blend):
Reject non-mult 2 lanes.
gcc/testsuite/ChangeLog:
PR tree-optimization/99825
* gfortran.dg/vect/pr99825.f90: New test.
When compiling with -mfloat-abi=hard -march=armv8.1-m.main+mve, we
want to emit Tag_ABI_VFP_args even though we are not emitting
floating-point instructions (we need "+mve.fp" for that), because we
use MVE registers to pass FP arguments.
This patch removes the condition on (! TARGET_SOFT_FLOAT) because this
is a case where TARGET_SOFT_FLOAT is true, and TARGET_HARD_FLOAT_ABI
is true too.
2021-03-30 Richard Earnshaw <rearnsha@arm.com>
gcc/
PR target/99773
* config/arm/arm.c (arm_file_start): Fix emission of
Tag_ABI_VFP_args attribute.
VN sometimes builds new integer types to handle accesss where precision
of the access type does not match the access size. The way
ao_ref_init_from_vn_reference is computing the access size ignores
the access type in case the ref operands have an outermost
COMPONENT_REF which, in case it is an array for example, can be
way larger than the access size. This can cause us to try
building an integer type with precision larger than WIDE_INT_MAX_PRECISION
eventually leading to memory corruption.
The following adjusts ao_ref_init_from_vn_reference to only lower
access sizes via the outermost COMPONENT_REF but otherwise honor
the access size as specified by the access type.
It also places an assert in integer type building that we remain
in the limits of WIDE_INT_MAX_PRECISION. I chose the shared code
where we set TYPE_MIN/MAX_VALUE because that will immediately
cross the wide_ints capacity otherwise.
2021-03-30 Richard Biener <rguenther@suse.de>
PR tree-optimization/99824
* stor-layout.c (set_min_and_max_values_for_integral_type):
Assert the precision is within the bounds of
WIDE_INT_MAX_PRECISION.
* tree-ssa-sccvn.c (ao_ref_init_from_vn_reference): Use
the outermost component ref only to lower the access size
and initialize that from the access type.
* gcc.dg/torture/pr99824.c: New testcase.
This PR is a regression caused by r8-5967, where we replaced
a call to aarch64_internal_mov_immediate in aarch64_add_offset
with a call to aarch64_force_temporary, which in turn uses the
normal emit_move_insn{,_1} routines.
The problem is that aarch64_add_offset can be called while
outputting a thunk, where we require all instructions to be
valid without splitting. However, the move expanders were
not splitting CONST_INT moves themselves.
I think the right fix is to make the move expanders work
even in this scenario, rather than require callers to handle
it as a special case.
gcc/
PR target/98136
* config/aarch64/aarch64.md (mov<mode>): Pass multi-instruction
CONST_INTs to aarch64_expand_mov_immediate when called after RA.
gcc/testsuite/
PR target/98136
* g++.dg/pr98136.C: New test.
Currently, SF->SI and DF->DI conversions on Aarch64 with the "nosimd"
flag provided sometimes cause the emitting of a vector variant of the
fcvtz[su] instruction (e.g. fcvtzu s0, s0).
This modifies the corresponding pattern to only select the vector
variant of the instruction when generating code with SIMD enabled.
gcc/ChangeLog:
* config/aarch64/aarch64.md
(<optab>_trunc<fcvt_target><GPI:mode>2): Set the "arch"
attribute to disambiguate between SIMD and FP variants of the
instruction.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/fcvt_nosimd.c: New test.
This is a regression present on the mainline: the compiler (front-end) fails
to assign an aggregate to a full-access component (i.e. Atomic or VFA) as a
whole if the type of the component is not full access itself.
gcc/ada/
PR ada/99802
* freeze.adb (Is_Full_Access_Aggregate): Call Is_Full_Access_Object
on the name of an N_Assignment_Statement to spot full access.
In the patch that I applied on March 2nd, I had code to provide support for
Decimal/_Float128 conversions if the user did not use at least GLIBC 2.32. It
did this by using __ibm128 as an intermediate type. The trouble is __ibm128
cannot represent all of the numbers that _Float128 can, and you lose if you do
this conversion.
This patch removes this support. The dfp-bit.c functions now call the the
__sprintfieee128 and __strtoieee128 functions to do the conversion. If the
user does not have GLIBC, they will get a linker error that these functions do
not exist.
The float128 support functions are only built into the static libgcc, so there
isn't an issue with having references to __strtoieee128 and __sprintfieee128
with older GLIBC libraries.
As an added bonus, this patch eliminates the __sprintfkf function which
included stdio.h to get a definition for the sprintf library function. This
allows for building cross compilers without having to have a target stdio.h
available.
libgcc/
2021-03-29 Michael Meissner <meissner@linux.ibm.com>
* config/rs6000/t-float128 (fp128_decstr_funcs): Delete.
(fp128_ppc_funcs): Do not add $(fp128_decstr_funcs).
(fp128_decstr_objs): Delete.
* dfp-bit.h: Call __sprintfieee128 to do conversions from
_Float128 to a Decimal type. Call __strtoieee128 to do
conversions from a Decimal type to _Float128.
* config/rs6000/_sprintfkf.c: Delete file.
* config/rs6000/_sprintfkf.h: Delete file.
* config/rs6000/_strtokf.c: Delete file.
* config/rs6000/_strtokf.h: Delete file.
aarch64 currently doesn't support declare simd where the return value and arguments
have different sizes and warns about that case. This change adds a dg-warning
for that case like various other tests have already.
2021-03-29 Jakub Jelinek <jakub@redhat.com>
PR fortran/93660
* gfortran.dg/gomp/declare-simd-coarray-lib.f90: Expect a mixed size
declare simd warning on aarch64.
The LLVM project renamed their default branch to 'main'.
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxx2017.xml: Adjust link for PSTL.
* doc/html/manual/status.html: Regenerate.
As discussed in the PR, we currently have two different numbering
schemes for SVE builtins: one for C, and one for C++. This is
problematic for LTO, where we end up getting confused about which
intrinsic we're talking about. This patch inserts placeholders into the
registered_functions vector to ensure that there is a consistent
numbering scheme for both C and C++.
We use integer_zero_node as a placeholder node instead of building a
function decl. This is safe because the node is only returned by the
TARGET_BUILTIN_DECL hook, which (on AArch64) is only used for validation
when builtin decls are streamed into lto1.
gcc/ChangeLog:
PR target/99216
* config/aarch64/aarch64-sve-builtins.cc
(function_builder::add_function): Add placeholder_p argument, use
placeholder decls if this is set.
(function_builder::add_unique_function): Instead of conditionally adding
direct overloads, unconditionally add either a direct overload or a
placeholder.
(function_builder::add_overloaded_function): Set placeholder_p if we're
using C++ overloads. Use the obstack for string storage instead
of relying on the tree nodes.
(function_builder::add_overloaded_functions): Don't return early for
m_direct_overloads: we need to add placeholders.
* config/aarch64/aarch64-sve-builtins.h
(function_builder::add_function): Add placeholder_p argument.
gcc/testsuite/ChangeLog:
PR target/99216
* g++.target/aarch64/sve/pr99216.C: New test.
This avoids asserting anything on the SLP_TREE_REPRESENTATIVE of
an SLP permute node (which shouldn't be there).
2021-03-29 Richard Biener <rguenther@suse.de>
PR tree-optimization/99807
* tree-vect-slp.c (vect_slp_analyze_node_operations_1): Move
assert below VEC_PERM handling.
* gfortran.dg/vect/pr99807.f90: New testcase.
This patch fixes the RTL representation of the move_lo_quad patterns to use aarch64_simd_or_scalar_imm_zero
for the zero part rather than a vec_duplicate of zero or a const_int 0.
The expander that generates them is also adjusted so that we use and match the correct const_vector forms throughout.
Co-Authored-By: Jakub Jelinek <jakub@redhat.com>
gcc/ChangeLog:
PR target/99037
* config/aarch64/aarch64-simd.md (move_lo_quad_internal_<mode>): Use
aarch64_simd_or_scalar_imm_zero to match zeroes. Remove pattern
matching const_int 0.
(move_lo_quad_internal_be_<mode>): Likewise.
(move_lo_quad_<mode>): Update for the above.
* config/aarch64/iterators.md (VQ_2E): Delete.
gcc/testsuite/ChangeLog:
PR target/99808
* gcc.target/aarch64/pr99808.c: New test.
extract_muldiv{,_1} is apparently only prepared to handle scalar integer
operations, the callers ensure it by only calling it if the divisor or
one of the multiplicands is INTEGER_CST and because neither multiplication
nor division nor modulo are really supported e.g. for pointer types, nullptr
type etc. But the CASE_CONVERT handling doesn't really check if it isn't
a cast from some other type kind, so on the testcase we end up trying to
build MULT_EXPR in POINTER_TYPE which ICEs. A few years ago Marek has
added ANY_INTEGRAL_TYPE_P checks to two spots, but the code uses
TYPE_PRECISION which means something completely different for vector types,
etc.
So IMNSHO we should just punt on conversions from non-integrals or
non-scalar integrals.
2021-03-29 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/99777
* fold-const.c (extract_muldiv_1): For conversions, punt on casts from
types other than scalar integral types.
* g++.dg/torture/pr99777.C: New test.
GCC currently emits TLS relocation decorations on symbols in DWARF sections.
Recent changes to the AIX linker cause it to reject such symbols.
This patch removes the decorations (@ie, @le, @m) and emit only the
qualified symbol name.
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_output_dwarf_dtprel): Do not add
XCOFF TLS reloc decorations.
I'm seeing random scan-assembler-times failures in pr96770.c when LTO is used.
I suspect this is because the \\+4 string matches the LTO sections, sometimes.
This small patch avoids the issue, by matching arr\\+4 instead of \\+4.
2021-03-28 Christophe Lyon <christophe.lyon@linaro.org>
gcc/testsuite/
PR target/96770
* gcc.target/arm/pure-code/pr96770.c: Improve scan-assembler-times.
2021-03-28 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran/ChangeLog
PR fortran/99602
* trans-expr.c (gfc_conv_procedure_call): Use the _data attrs
for class expressions and detect proc pointer evaluations by
the non-null actual argument list.
gcc/testsuite/ChangeLog
PR fortran/99602
* gfortran.dg/pr99602.f90: New test.
* gfortran.dg/pr99602a.f90: New test.
* gfortran.dg/pr99602b.f90: New test.
* gfortran.dg/pr99602c.f90: New test.
* gfortran.dg/pr99602d.f90: New test.
Christophe Lyon
H.J. Lu
Richard Sandiford
Jan Hubicka
Martin Liska
Jakub Jelinek
Patrick Palka
GCC Administrator
David Malcolm
Nathan Sidwell
Kyrylo Tkachov
luoxhu@cn.ibm.com
Tamar Christina
Richard Biener
Mihailo Stojanovic
Joseph Myers
Eric Botcazou
Martin Sebor
Michael Meissner
Jonathan Wakely
Alex Coplan
Tobias Burnus
David Edelsohn
Gerald Pfeifer
François Dumont
Paul Thomas