A couple of analyzer testcases no longer have state explosions; updating
them accordingly in case they regress.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/pr94047.c: Remove "-Wno-analyzer-too-complex".
* gcc.dg/analyzer/zlib-2.c: Likewise.
The target selector should explicitly choose 256 bit hardware as
explicit 256 bit compiler options are used to trigger the bug.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/pr99102.c: Fix target selector.
Previously, IFN_MASK_SCATTER_STORE was used if 'loop_masks' was
non-null, but the mask used is 'final_mask'. This caused a bug where
a 'MASK_STORE' was vectorized into a 'SCATTER_STORE' instead of a
'MASK_SCATTER_STORE'. This fixes PR target/99102.
gcc/ChangeLog:
PR target/99102
* tree-vect-stmts.c (vectorizable_store): Fix scatter store mask
check condition.
(vectorizable_load): Fix gather load mask check condition.
gcc/testsuite/ChangeLog:
PR target/99102
* gcc.dg/vect/pr99102.c: New test.
The fix for PR94775 added more strict checking for type reuse
to check_aligned_type, specifically matching TYPE_USER_ALIGN.
But then build_aligned_type sets TYPE_USER_ALIGN on the built
variant so if the type we build an aligned variant for does not
have TYPE_USER_ALIGN we'll never re-use the newly created aligned
variant. This results in ~35000 identical variants being created
for polyhedron doduc.
The following instead checks that the candidate has TYPE_USER_ALIGN set.
2021-03-10 Richard Biener <rguenther@suse.de>
PR tree-optimization/99510
* tree.c (check_aligned_type): Check that the candidate
has TYPE_USER_ALIGN set instead of matching with the
original type.
The code in build_round_expr implicitly assumes that __float128 exists,
which is *not* the common case among 64-bit architectures since the
"long double" type is generally already 128-bit for them.
gcc/fortran/
PR fortran/96983
* trans-intrinsic.c (build_round_expr): Do not implicitly assume
that __float128 is the 128-bit floating-point type.
This is a strange regression whereby an enumeration type declared as
atomic (or volatile) incorrectly triggers the ODR machinery for its
values in LTO mode.
gcc/ada/
* gcc-interface/decl.c (gnat_to_gnu_entity): Build a TYPE_STUB_DECL
for the main variant of an enumeration type declared as volatile.
gcc/testsuite/
* gnat.dg/specs/lto25.ads: New test.
Returning a REGMODE_NATURAL_SIZE of 4 for DFmode in 64-bit mode is
just asking for trouble because sub-word SUBREGs are always treated
differently than the others, in particular by the register allocator.
gcc/
* config/sparc/sparc.c (sparc_regmode_natural_size): Return 4 for
float and vector integer modes only if the mode is not larger.
When DWARF_FRAME_REGISTERS isn't defined, the default is
FIRST_PSEUDO_REGISTER which means that if you add faked
registers to the port, used for frame-context related
elimination, room is allocated for them in the register
context used for frame-unwinding, which is wasteful because
they're eliminated before the final form of the code that is
emitted.
Stopping after MOF saves two register slots in the unwind
contest, compared to the current default. For regular C
programming this is uninteresting, but defining
DWARF_FRAME_REGISTERS now also avoids the need to remember
to define it later, when twiddling with additional faked
registers (alternatively suffering churn from comparing
differences in unwind context). As expected, no effect on
test-results, coremark or local (C-specific)
microbenchmarks.
gcc:
* config/cris/cris.h (DWARF_FRAME_REGISTERS): Define.
Fix build errors due to warnings such as:
gcc/config/v850/rtems.h:43: error: "RTEMS_STARTFILE_SPEC" redefined [-Werror]
43 | #define RTEMS_STARTFILE_SPEC ""
The problem was that "gcc/config/rtems.h" was included before the
architecture-specific "gcc/config/*/rtems.h" header file on some
architectures.
gcc/
* config.gcc (aarch64-*-rtems*): Include general rtems.h after
the architecture-specific rtems.h.
(aarch64-*-rtems*): Likewise.
(arm*-*-rtems*): Likewise.
(epiphany-*-rtems*): Likewise.
(riscv*-*-rtems*): Likewise.
Before my PR97690 changes, conditional_replacement would not set neg
when the nonzero arg was boolean true.
I've simplified the testing, so that it first finds the zero argument
and then checks the other argument for all the handled cases
(1, -1 and 1 << X, where the last case is what the patch added support for).
But, unfortunately I've placed the integer_all_onesp test first.
For unsigned precision 1 types such as bool integer_all_onesp, integer_onep
and integer_pow2p can all be true and the code set neg to true in that case,
which is undesirable.
The following patch tests integer_pow2p first (which is trivially true
for integer_onep too and tree_log2 in that case gives shift == 0)
and only if that isn't the case, integer_all_onesp.
2021-03-09 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/99305
* tree-ssa-phiopt.c (conditional_replacement): Test integer_pow2p
before integer_all_onesp instead of vice versa.
* g++.dg/opt/pr99305.C: New test.
The previous version returned true for all PowerPC. This is incorrect.
We only support floating point square root instructions if a) we support
floating point instructions at all, and b) we have _ARCH_PPCSQ defined.
2020-03-09 Segher Boessenkool <segher@kernel.crashing.org>
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_powerpc_sqrt): New.
(check_effective_target_sqrt_insn): Use it.
gcc/ChangeLog:
PR target/99454
* lra-constraints.c (process_address_1): Process constraint 'g'
separately and digital constraints containing more one digit.
gcc/testsuite/ChangeLog:
PR target/99454
* gcc.target/i386/pr99454.c: New.
The r11-7528 build_co_await changes broke coroutines on arm*-linux-gnuabi,
2780 ^FAIL.*coroutines/ in total.
The problem is that arm is targetm.cxx.cdtor_return_this target where
both ctors and dtors in the ABI return this pointer rather than
void, and build_new_method_call_1 does:
else if (call != error_mark_node
&& DECL_DESTRUCTOR_P (cand->fn)
&& !VOID_TYPE_P (TREE_TYPE (call)))
/* An explicit call of the form "x->~X()" has type
"void". However, on platforms where destructors
return "this" (i.e., those where
targetm.cxx.cdtor_returns_this is true), such calls
will appear to have a return value of pointer type
to the low-level call machinery. We do not want to
change the low-level machinery, since we want to be
able to optimize "delete f()" on such platforms as
"operator delete(~X(f()))" (rather than generating
"t = f(), ~X(t), operator delete (t)"). */
call = build_nop (void_type_node, call);
The new code in build_co_await relies on build_special_member_call
returned expression being a CALL_EXPR, but due to the build_nop
in there it is a NOP_EXPR around the CALL_EXPR. It can't be stripped
with STRIP_NOPS because void has different mode from the pointer mode.
2021-03-09 Jakub Jelinek <jakub@redhat.com>
PR c++/99459
* coroutines.cc (build_co_await): Look through NOP_EXPRs in
build_special_member_call return value to find the CALL_EXPR.
Simplify.
First, gcc.dg/array-quals-1.c does not pass if the compiler is configured
with --enable-default-pie because the sections change, so force -fno-pie.
Second, replace *-*-solaris* with sparc*-*-* for gfortran.dg/pr95690.f90
because this depends on the architecture rather than the OS. Third force
SRA to trigger on Aarch64 (like PowerPC) for gnat.dg/opt39.adb.
gcc/testsuite/
* gcc.dg/array-quals-1.c: Pass -fno-pie if supported.
* gcc.dg/loop-9.c: Likewise.
* gfortran.dg/pr95690.f90: Replace *-*-solaris* with sparc*-*-*.
* gnat.dg/opt39.adb: Pass --param option for Aarch64 too.
This boils down to the RTL expander trying to take the address of a DECL
whose RTX is a register.
gcc/
PR c++/90448
* calls.c (initialize_argument_information): When the argument
is passed by reference, do not make a copy in a thunk only if
the argument is already in memory. Remove redundant test for
the case of callee copy.
We need to process 0..9 constraints to fetch the right op constraint in
the function. Also 0..9 constraints gives unknown class constraint
class which can result in skipping address normalization for memory in asm.
gcc/ChangeLog:
PR target/99454
* lra-constraints.c (process_address_1): Process 0..9 constraints
in process_address_1.
Not all OSes have regex.h and not all OSes that do have REG_STARTEND macro support.
Conditionalize the test on that.
2021-03-09 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/98920
* c-c++-common/asan/pr98920.c: Only include regex.h if the header
exists. If REG_STARTEND macro isn't defined, just return 0 from main
instead of the actual test.
This clarifies that c++2[03] intentionally does not enable
c++20 modules.
PR c++/99472
gcc/cp/
* parser.c (cp_parser_diagnose_invalid_type_name): Clarify
that C++20 does not yet imply modules.
gcc/ChangeLog:
PR target/99464
* config/i386/i386-options.c (ix86_option_override_internal):
Set isa_flags for OPTS argument and not for the global
global_options.
gcc/testsuite/ChangeLog:
PR target/99464
* gcc.target/i386/pr99464.c: New test.
Not sure what I did but this corrects it to the version that I tested
and that Segher approved.
gcc/ChangeLog
* config/rs6000/predicates.md (ds_form_mem_operand): Check
in correct code.
These tests use -mvsx in their dg-options lists, so they are only
applicable if the -mvsx option is supported by the compiler.
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/undef-bool-2.c: Add
dg-require-effective-target powerpc_vsx_ok directive.
* g++.dg/ext/undef-bool-1.C: Add dg-require-effective-target
powerpc_vsx_ok directive.
PR99070 is caused by a fusion pattern matching that the individual
instructions do not match when it is split later. In this case the
ld+cmpi patterns were allowing a d-form load address, which the split
condition would rightly split, however that left us with something that
could not be matched by a ds-form ld instruction, hence the ICE. This
only happened if the target cpu was not power10 -- if we were targeting
power10 then a prefixed pld instruction would get generated because that
can handle d-form. However this is not optimal code either.
So the solution is a new predicate (ds_form_mem_operand) that only
accepts what we can take as for a ds-form load. Then a small
modification of the genfusion.pl script changes the relevant
ld+cmpi patterns to use the new predicate.
gcc/ChangeLog
PR target/99070
* config/rs6000/predicates.md (ds_form_mem_operand) New
predicate.
* config/rs6000/genfusion.pl (gen_ld_cmpi_p10) Use
ds_form_mem_operand in ld/lwa patterns.
* config/rs6000/fusion.md: Regenerate file.
A variable with the PARAMETER attribute may not appear in a DATA statement.
gcc/fortran/ChangeLog:
PR fortran/49278
* data.c (gfc_assign_data_value): Reject variable with PARAMETER
attribute in DATA statement.
gcc/testsuite/ChangeLog:
PR fortran/49278
* gfortran.dg/parameter_data.f90: New test.
gcc/ChangeLog:
PR middle-end/98266
* gimple-array-bounds.cc (inbounds_vbase_memaccess_p): New function.
(array_bounds_checker::check_array_bounds): Call it.
gcc/testsuite/ChangeLog:
PR middle-end/98266
* g++.dg/warn/Warray-bounds-15.C: New test.
* g++.dg/warn/Warray-bounds-18.C: New test.
* g++.dg/warn/Warray-bounds-19.C: New test.
* g++.dg/warn/Warray-bounds-20.C: New test.
* g++.dg/warn/Warray-bounds-21.C: New test.
This works since the recent r11-7102, but we didn't have a test for
a template-argument context.
gcc/testsuite/ChangeLog:
PR c++/96268
* g++.dg/cpp2a/nontype-class41.C: New test.
This adds support for c++23 mode to modules, and enables such testing.
PR c++/99436
gcc/cp/
* name-lookup.c (get_cxx_dialect_name): Add cxx23.
gcc/testsuite/
* g++.dg/modules/modules.exp (MOD_STD_LIST): Add 2b.
We didn't specifically check for a module-decl inside a header unit.
That leads to a confusing diagostic. Fixed thusly.
gcc/cp/
* lex.c (module_token_filter::resume): Ignore module-decls inside
header-unit.
* parser.c (cp_parser_module_declaration): Reject in header-unit.
gcc/testsuite/
* g++.dg/modules/pr99468.H: New.
The rs6000_emit_le_vsx_* functions assume they are not passed an Altivec
style "& ~16" address. However, some of our expanders and splitters do
not verify we do not have an Altivec style address before calling those
functions, leading to an ICE. The solution here is to guard the expanders
and splitters to ensure we do not call them if we're given an Altivec style
address.
2021-03-08 Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/98959
* config/rs6000/rs6000.c (rs6000_emit_le_vsx_permute): Add an assert
to ensure we do not have an Altivec style address.
* config/rs6000/vsx.md (*vsx_le_perm_load_<mode>): Disable if passed
an Altivec style address.
(*vsx_le_perm_store_<mode>): Likewise.
(splitters after *vsx_le_perm_store_<mode>): Likewise.
(vsx_load_<mode>): Disable special expander if passed an Altivec
style address.
(vsx_store_<mode>): Likewise.
gcc/testsuite/
PR target/98959
* gcc.target/powerpc/pr98959.c: New test.
Class template partial specializations need to be in the
specialization hash, but not all of them. This defers adding
streamed-in entities to the hash table, in the same way I deferred
adding the instantiation and specialization lists for 99170.
PR c++/99285
gcc/cp/
* cp-tree.h (match_mergeable_specialization)
(add_mergeable_specialization): Adjust parms.
* module.cc (trees_in::decl_value): Adjust
add_mergeable_specialization calls.
(trees_out::key_mergeable): Adjust match_mergeable_specialization
calls.
(specialization_add): Likewise.
* pt.c (match_mergeable_specialization): Do not insert.
(add_mergeable_specialization): Add to hash table here.
gcc/testsuite/
* g++.dg/modules/pr99285_a.H: New.
* g++.dg/modules/pr99285_b.H: New.
In this bug combine forms the (R)SHRN(2) instructions with an invalid shift amount.
The intrinsic expanders for these patterns validate the right shift amount but if the
final patterns end up being matched by combine (or other RTL passes I suppose) they
still let the wrong const_vector through.
This patch tightens up the predicates for the instructions involved by using predicates
for the right shift amount const_vectors.
gcc/ChangeLog:
PR target/99437
* config/aarch64/predicates.md (aarch64_simd_shift_imm_vec_qi): Define.
(aarch64_simd_shift_imm_vec_hi): Likewise.
(aarch64_simd_shift_imm_vec_si): Likewise.
(aarch64_simd_shift_imm_vec_di): Likewise.
* config/aarch64/aarch64-simd.md (aarch64_shrn<mode>_insn_le): Use
predicate from above.
(aarch64_shrn<mode>_insn_be): Likewise.
(aarch64_rshrn<mode>_insn_le): Likewise.
(aarch64_rshrn<mode>_insn_be): Likewise.
(aarch64_shrn2<mode>_insn_le): Likewise.
(aarch64_shrn2<mode>_insn_be): Likewise.
(aarch64_rshrn2<mode>_insn_le): Likewise.
(aarch64_rshrn2<mode>_insn_be): Likewise.
gcc/testsuite/ChangeLog:
PR target/99437
* gcc.target/aarch64/simd/pr99437.c: New test.
Function process_address_1 can wrongly look at constraint modifiers
instead of the 1st constraint itself. The patch solves the problem.
gcc/ChangeLog:
PR target/99422
* lra-constraints.c (skip_contraint_modifiers): New function.
(process_address_1): Use it before lookup_constraint call.
gcc/ChangeLog:
PR target/99463
* config/i386/i386-options.c (ix86_option_override_internal):
Enable UINTR and HRESET for -march that supports it.
gcc/testsuite/ChangeLog:
PR target/99463
* gcc.target/i386/pr99463-2.c: New test.
* gcc.target/i386/pr99463.c: New test.
After switching the s390 backend to store long doubles in vector
registers, "f" constraint broke when used with the former: long doubles
correspond to TFmode, which in combination with "f" corresponds to
hard regs %v0-%v15, however, asm users expect a %f0-%f15 pair.
Fix by using TARGET_MD_ASM_ADJUST hook to convert TFmode values to
FPRX2mode and back.
gcc/ChangeLog:
2020-12-14 Ilya Leoshkevich <iii@linux.ibm.com>
* config/s390/s390.c (f_constraint_p): New function.
(s390_md_asm_adjust): Implement TARGET_MD_ASM_ADJUST.
(TARGET_MD_ASM_ADJUST): Likewise.
gcc/testsuite/ChangeLog:
2020-12-14 Ilya Leoshkevich <iii@linux.ibm.com>
* gcc.target/s390/vector/long-double-asm-commutative.c: New
test.
* gcc.target/s390/vector/long-double-asm-earlyclobber.c: New
test.
* gcc.target/s390/vector/long-double-asm-in-out.c: New test.
* gcc.target/s390/vector/long-double-asm-inout.c: New test.
* gcc.target/s390/vector/long-double-asm-matching.c: New test.
* gcc.target/s390/vector/long-double-asm-regmem.c: New test.
* gcc.target/s390/vector/long-double-volatile-from-i64.c: New
test.
