Andreas Krebbel [Fri, 6 Mar 2020 08:51:34 +0000 (09:51 +0100)]
Fix error format string.
gcc/ChangeLog:
2020-03-06 Andreas Krebbel <krebbel@linux.ibm.com>
* config/s390/s390.md ("tabort"): Get rid of two consecutive
blanks in format string.
Kito Cheng [Tue, 3 Mar 2020 06:16:42 +0000 (14:16 +0800)]
re PR tree-optimization/90883 (Generated code is worse if returned struct is unnamed)
After add --param max-inline-insns-size=1 all target will remove the
redundant store at dse1, except some targets like AArch64 and MIPS will
expand the struct initialization into loop due to CLEAR_RATIO.
Tested on cross compiler of riscv32, riscv64, x86, x86_64, mips, mips64,
aarch64, nds32 and arm.
gcc/testsuite/ChangeLog
PR tree-optimization/90883
* g++.dg/tree-ssa/pr90883.c: Add --param max-inline-insns-size=1.
Add aarch64-*-* mips*-*-* to XFAIL.
H.J. Lu [Fri, 6 Mar 2020 00:45:05 +0000 (16:45 -0800)]
i386: Properly encode vector registers in vector move
On x86, when AVX and AVX512 are enabled, vector move instructions can
be encoded with either 2-byte/3-byte VEX (AVX) or 4-byte EVEX (AVX512):
0: c5 f9 6f d1 vmovdqa %xmm1,%xmm2
4: 62 f1 fd 08 6f d1 vmovdqa64 %xmm1,%xmm2
We prefer VEX encoding over EVEX since VEX is shorter. Also AVX512F
only supports 512-bit vector moves. AVX512F + AVX512VL supports 128-bit
and 256-bit vector moves. xmm16-xmm31 and ymm16-ymm31 are disallowed in
128-bit and 256-bit modes when AVX512VL is disabled. Mode attributes on
x86 vector move patterns indicate target preferences of vector move
encoding. For scalar register to register move, we can use 512-bit
vector move instructions to move 32-bit/64-bit scalar if AVX512VL isn't
available. With AVX512F and AVX512VL, we should use VEX encoding for
128-bit/256-bit vector moves if upper 16 vector registers aren't used.
This patch adds a function, ix86_output_ssemov, to generate vector moves:
1. If zmm registers are used, use EVEX encoding.
2. If xmm16-xmm31/ymm16-ymm31 registers aren't used, SSE or VEX encoding
will be generated.
3. If xmm16-xmm31/ymm16-ymm31 registers are used:
a. With AVX512VL, AVX512VL vector moves will be generated.
b. Without AVX512VL, xmm16-xmm31/ymm16-ymm31 register to register
move will be done with zmm register move.
There is no need to set mode attribute to XImode explicitly since
ix86_output_ssemov can properly encode xmm16-xmm31/ymm16-ymm31 registers
with and without AVX512VL.
Tested on AVX2 and AVX512 with and without --with-arch=native.
gcc/
PR target/89229
PR target/89346
* config/i386/i386-protos.h (ix86_output_ssemov): New prototype.
* config/i386/i386.c (ix86_get_ssemov): New function.
(ix86_output_ssemov): Likewise.
* config/i386/sse.md (VMOVE:mov<mode>_internal): Call
ix86_output_ssemov for TYPE_SSEMOV. Remove TARGET_AVX512VL
check.
(*movxi_internal_avx512f): Call ix86_output_ssemov for TYPE_SSEMOV.
(*movoi_internal_avx): Call ix86_output_ssemov for TYPE_SSEMOV.
Remove ext_sse_reg_operand and TARGET_AVX512VL check.
(*movti_internal): Likewise.
(*movtf_internal): Call ix86_output_ssemov for TYPE_SSEMOV.
gcc/testsuite/
PR target/89229
PR target/89346
* gcc.target/i386/avx512vl-vmovdqa64-1.c: Updated.
* gcc.target/i386/pr89229-2a.c: New test.
* gcc.target/i386/pr89229-2b.c: Likewise.
* gcc.target/i386/pr89229-2c.c: Likewise.
* gcc.target/i386/pr89229-3a.c: Likewise.
* gcc.target/i386/pr89229-3b.c: Likewise.
* gcc.target/i386/pr89229-3c.c: Likewise.
* gcc.target/i386/pr89346.c: Likewise.
GCC Administrator [Fri, 6 Mar 2020 00:16:34 +0000 (00:16 +0000)]
Daily bump.
Andre Vieira [Thu, 5 Mar 2020 23:59:53 +0000 (16:59 -0700)]
[PATCH][testuite] Fix pr80481.C after epilogue vectorization
* g++.dg/pr80481.C: Disable epilogue vectorization.
Joseph Myers [Thu, 5 Mar 2020 23:48:06 +0000 (23:48 +0000)]
c: ignore initializers for elements of variable-size types [PR93577]
Bug 93577, apparently a regression (although it isn't very clear to me
exactly when it was introduced; tests I made with various past
compilers produced inconclusive results, including e.g. ICEs appearing
with 64-bit-host compilers for some versions but not 32-bit-host
compilers for the same versions) is an C front-end tree-checking ICE
processing initializers for structs using the VLA-in-struct extension.
There is an error for such initializers, but other processing that
still takes place for them results in the ICE.
This patch ensures that processing of initializers for variable-size
types stops earlier to avoid the code that results in the ICE (and
ensures it stops earlier for error_mark_node to avoid ICEs in the
check for variable-size types), adjusts the conditions for the "empty
scalar initializer" diagnostic to avoid consequent excess errors in
the case of a bad type name, and adds tests for a few variations on
what such initializers might look like, as well as tests for cases
identified from ICEs seen with an earlier version of this patch.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/93577
gcc/c:
* c-typeck.c (pop_init_level): Do not diagnose initializers as
empty when initialized type is error_mark_node.
(set_designator, process_init_element): Ignore initializers for
elements of a variable-size type or of error_mark_node.
gcc/testsuite:
* gcc.dg/pr93577-1.c, gcc.dg/pr93577-2.c, gcc.dg/pr93577-3.c,
gcc.dg/pr93577-4.c, gcc.dg/pr93577-5.c, gcc.dg/pr93577-6.c: New
tests.
* gcc.dg/vla-init-1.c: Expect fewer errors about VLA initializer.
Jeff Law [Thu, 5 Mar 2020 21:16:02 +0000 (14:16 -0700)]
Commit correct version of gimple.c file
Jeff Law [Thu, 5 Mar 2020 21:01:30 +0000 (14:01 -0700)]
Fix location maybe_diag_overlap passes to diagnostics so that diagnostic pragmas work better.
PR tree-optimization/91890
* gimple-ssa-warn-restrict.c (maybe_diag_overlap): Remove LOC argument.
Use gimple_or_expr_nonartificial_location.
(check_bounds_overlap): Drop LOC argument to maybe_diag_access_bounds.
Use gimple_or_expr_nonartificial_location.
* gimple.c (gimple_or_expr_nonartificial_location): New function.
* gimple.h (gimple_or_expr_nonartificial_location): Declare it.
* tree-ssa-strlen.c (maybe_warn_overflow): Use
gimple_or_expr_nonartificial_location.
(maybe_diag_stxncpy_trunc, handle_builtin_stxncpy_strncat): Likewise.
(maybe_warn_pointless_strcmp): Likewise.
* gcc.dg/pragma-diag-8.c: New test.
Jakub Jelinek [Thu, 5 Mar 2020 18:44:42 +0000 (19:44 +0100)]
i386: Fix some -O0 avx2intrin.h and xopintrin.h intrinsic macros [PR94046]
As the testcases show, the macros we have for -O0 for intrinsics that require
constant argument(s) should first cast the argument to the type the -O1+
inline uses and afterwards to whatever type e.g. a builtin needs.
The PR reported one which violated this, and I've grepped for all double-casts
and grepped out from that meaningful casts where the __m{128,256,512}{,d,i}
first cast is cast to same sized __v* type and has the same kind of element
type (float, double, integral). These 7 macros were using different casts,
and I've double checked them against the inline function types.
2020-03-05 Jakub Jelinek <jakub@redhat.com>
PR target/94046
* config/i386/avx2intrin.h (_mm_mask_i32gather_ps): Fix first cast of
SRC and MASK arguments to __m128 from __m128d.
(_mm256_mask_i32gather_ps): Fix first cast of MASK argument to __m256
from __m256d.
(_mm_mask_i64gather_ps): Fix first cast of MASK argument to __m128
from __m128d.
* config/i386/xopintrin.h (_mm_permute2_pd): Fix first cast of C
argument to __m128i from __m128d.
(_mm256_permute2_pd): Fix first cast of C argument to __m256i from
__m256d.
(_mm_permute2_ps): Fix first cast of C argument to __m128i from __m128.
(_mm256_permute2_ps): Fix first cast of C argument to __m256i from
__m256.
* g++.target/i386/pr94046-1.C: New test.
* g++.target/i386/pr94046-2.C: New test.
Kyrylo Tkachov [Thu, 5 Mar 2020 17:45:58 +0000 (17:45 +0000)]
[AArch32] ACLE intrinsics bfloat16 vmmla and vfma<b/t> for AArch32 AdvSIMD
Commit rest of the
43031fbdda7d4edbd607365a4f3bbec069fe3983 content.
I screwed up on the "git add" commands there.
Jonathan Wakely [Thu, 5 Mar 2020 17:21:24 +0000 (17:21 +0000)]
libstdc++: Fix some warnings in filesystem tests
There's a -Wunused-but-set-variable warning in operations/all.cc which
can be fixed with [[maybe_unused]].
The statements in operations/copy.cc give -Wunused-value warnings. I
think I meant to use |= rather than !=.
And operations/file_size.cc gets -Wsign-compare warnings.
* testsuite/27_io/filesystem/operations/all.cc: Mark unused variable.
* testsuite/27_io/filesystem/operations/copy.cc: Fix typo.
* testsuite/experimental/filesystem/operations/copy.cc: Likewise.
* testsuite/27_io/filesystem/operations/file_size.cc: Use correct type
for return value, and in comparison.
* testsuite/experimental/filesystem/operations/file_size.cc: Likewise.
Uros Bizjak [Thu, 5 Mar 2020 16:51:11 +0000 (17:51 +0100)]
testsuite: Compile asan_test.C with -Wno-alloc-size-larger-than
asan_test.cc tries to allocate 0xf0000000 bytes for 32bit targets in
a disabled DISABLED_DemoOOM test. Since the testcase is compiled with
-Werror, the compilation fails with:
error: argument 1 value '
4026531840' exceeds maximum object size
2147483647
Compile with -Wno-alloc-size-larger-than to avoid compilation failure.
* g++.dg/asan/asan_test.C (dg-options): Add
-Wno-alloc-size-larger-than.
Jonathan Wakely [Thu, 5 Mar 2020 16:46:28 +0000 (16:46 +0000)]
libstdc++: allow string_view insertion to work with <iosfwd> (PR 94051)
I don't think this is actually required to compile, because using
operator<< without a definition of the ostream doesn't seem valid to me.
But it's easy to make it work.
PR libstdc++/94051
* include/std/string_view: Include <bits/ostream_insert.h>.
* testsuite/21_strings/basic_string_view/inserters/94051.cc: New test.
Jakub Jelinek [Thu, 5 Mar 2020 15:59:58 +0000 (16:59 +0100)]
testsuite: Add testcase for already fixed PR [PR90311]
2020-03-05 Jakub Jelinek <jakub@redhat.com>
PR target/90311
* gcc.c-torture/execute/pr90311.c: New test.
Jeff Law [Thu, 5 Mar 2020 15:46:20 +0000 (08:46 -0700)]
Future proofing this test.
* gcc.target/arm/fuse-caller-save.c: Generalize expected output.
Jason Merrill [Thu, 5 Mar 2020 15:11:36 +0000 (10:11 -0500)]
c++: Add test for PR91607.
PR c++/91607
* g++.dg/cpp0x/constexpr-const3.C: New.
Steven G. Kargl [Thu, 5 Mar 2020 11:41:14 +0000 (11:41 +0000)]
Fortran: ICE in gfc_code2string PR93792
A BOZ constant can not appear as a component inialiser for a derived
type.
gcc/fortran/ChangeLog:
PR93792
* decl.c (variable_decl): If param and initializer check
for BOZ, if found, output an error, set m to MATCH_ERROR
and goto cleanup.
gcc/testsuite/ChangeLog:
PR93792
* gfortran.dg/pr93792.f90: New test.
Delia Burduv [Thu, 5 Mar 2020 11:18:04 +0000 (11:18 +0000)]
[AArch32] ACLE intrinsics bfloat16 vmmla and vfma<b/t> for AArch32 AdvSIMD
This patch adds the ARMv8.6 ACLE intrinsics for vmmla, vfmab and vfmat
as part of the BFloat16 extension.
(https://developer.arm.com/docs/101028/latest.)
The intrinsics are declared in arm_neon.h and the RTL patterns are
defined in neon.md.
Two new tests are added to check assembler output and lane indices.
2020-03-05 Delia Burduv <delia.burduv@arm.com>
* config/arm/arm_neon.h (vbfmmlaq_f32): New.
(vbfmlalbq_f32): New.
(vbfmlaltq_f32): New.
(vbfmlalbq_lane_f32): New.
(vbfmlaltq_lane_f32): New.
(vbfmlalbq_laneq_f32): New.
(vbfmlaltq_laneq_f32): New.
* config/arm/arm_neon_builtins.def (vmmla): New.
(vfmab): New.
(vfmat): New.
(vfmab_lane): New.
(vfmat_lane): New.
(vfmab_laneq): New.
(vfmat_laneq): New.
* config/arm/iterators.md (BF_MA): New int iterator.
(bt): New int attribute.
(VQXBF): Copy of VQX with V8BF.
* config/arm/neon.md (neon_vmmlav8bf): New insn.
(neon_vfma<bt>v8bf): New insn.
(neon_vfma<bt>_lanev8bf): New insn.
(neon_vfma<bt>_laneqv8bf): New expand.
(neon_vget_high<mode>): Changed iterator to VQXBF.
* config/arm/unspecs.md (UNSPEC_BFMMLA): New UNSPEC.
(UNSPEC_BFMAB): New UNSPEC.
(UNSPEC_BFMAT): New UNSPEC.
2020-03-05 Delia Burduv <delia.burduv@arm.com>
* gcc.target/arm/simd/bf16_ma_1.c: New test.
* gcc.target/arm/simd/bf16_ma_2.c: New test.
* gcc.target/arm/simd/bf16_mmla_1.c: New test.
Srinath Parvathaneni [Thu, 5 Mar 2020 11:07:11 +0000 (11:07 +0000)]
[PATCH][GCC]: Add myself to MAINTAINERS
Jakub Jelinek [Thu, 5 Mar 2020 08:12:44 +0000 (09:12 +0100)]
print-rtl: Fix printing of CONST_STRING in DEBUG_INSNs [PR93399]
The following testcase fails to assemble, as CONST_STRING in the DEBUG_INSNs
is printed as is, so if it contains \n and/or \r, we are in trouble:
.loc 1 14 3
# DEBUG haystack => [si]
# DEBUG needle => "
"
In the gimple dumps we print those (STRING_CSTs) as
# DEBUG haystack => D#1
# DEBUG needle => "\n"
so this patch uses what we use in tree printing for the CONST_STRINGs too.
2020-03-05 Jakub Jelinek <jakub@redhat.com>
PR middle-end/93399
* tree-pretty-print.h (pretty_print_string): Declare.
* tree-pretty-print.c (pretty_print_string): Remove forward
declaration, no longer static. Change nbytes parameter type
from unsigned to size_t.
* print-rtl.c (print_value) <case CONST_STRING>: Use
pretty_print_string and for shrink way too long strings.
* gcc.dg/pr93399.c: New test.
Richard Biener [Thu, 5 Mar 2020 07:44:11 +0000 (08:44 +0100)]
Keep .GCC.command.line sections of LTO objetcs
This patch is for .GCC.command.line sections in LTO objects to be copied
into the final objects as in the following example:
[egeyar@localhost lto]$ gcc -flto -O3 demo.c -c -g --record-gcc-command-line
[egeyar@localhost lto]$ gcc -flto -O2 demo2.c -c -g --record-gcc-command-line -DFORTIFY=2
[egeyar@localhost lto]$ gcc demo.o demo2.o -o a.out
[egeyar@localhost lto]$ readelf -p .GCC.command.line a.out
String dump of section '.GCC.command.line':
[ 0] 10.0.1
20200227 (experimental) : gcc -flto -O3 demo.c -c -g --record-gcc-command-line
[ 56] 10.0.1
20200227 (experimental) : gcc -flto -O2 demo2.c -c -g --record-gcc-command-line -DFORTIFY=2
2020-03-05 Egeyar Bagcioglu <egeyar.bagcioglu@oracle.com>
* simple-object.c (handle_lto_debug_sections): Name
".GCC.command.line" among debug sections to be copied over
from lto objects.
Jakub Jelinek [Thu, 5 Mar 2020 07:00:04 +0000 (08:00 +0100)]
sccvn: Fix handling of POINTER_PLUS_EXPR in memset offset [PR93582]
> > where POINTER_PLUS_EXPR last operand has sizetype type, thus unsigned,
> > and in the testcase gimple_assign_rhs2 (def) is thus 0xf000000000000001ULL
> > which multiplied by 8 doesn't fit into signed HWI. If it would be treated
> > as signed offset instead, it would fit (-0xfffffffffffffffLL, multiplied
> > by 8 is -0x7ffffffffffffff8LL). Unfortunately with the poly_int obfuscation
> > I'm not sure how to convert it from unsigned to signed poly_int.
>
> mem_ref_offset provides a boiler-plate for this:
>
> poly_offset_int::from (wi::to_poly_wide (TREE_OPERAND (t, 1)), SIGNED);
Thanks, that seems to work.
The test now works on both big-endian and little-endian.
2020-03-05 Richard Biener <rguenther@suse.de>
Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/93582
* tree-ssa-sccvn.c (vn_reference_lookup_3): Treat POINTER_PLUS_EXPR
last operand as signed when looking for memset offset. Formatting
fix.
* gcc.dg/tree-ssa/pr93582-11.c: New test.
Co-authored-by: Richard Biener <rguenther@suse.de>
Martin Sebor [Thu, 5 Mar 2020 01:19:31 +0000 (18:19 -0700)]
PR c++/90938 - Initializing array with {1} works but not {0}
gcc/cp/ChangeLog:
PR c++/90938
* tree.c (type_initializer_zero_p): Fail for structs initialized
with non-structs.
gcc/testsuite/ChangeLog:
PR c++/90938
* g++.dg/init/array55.C: New test.
* g++.dg/init/array56.C: New test.
* g++.dg/cpp2a/nontype-class33.C: New test.
GCC Administrator [Thu, 5 Mar 2020 00:16:34 +0000 (00:16 +0000)]
Daily bump.
Jeff Law [Wed, 4 Mar 2020 23:25:11 +0000 (16:25 -0700)]
Fix format warning which showed up on FreeBSD 11.3.
PR bootstrap/93962
* value-prof.c (dump_histogram_value): Use std::abs.
Jason Merrill [Wed, 4 Mar 2020 17:08:42 +0000 (12:08 -0500)]
c++: Fix [[no_unique_address]] and default mem-init [PR90432]
output_constructor doesn't like two consecutive entries with fields at the
same position; let's avoid adding the one for the empty field.
gcc/cp/ChangeLog
2020-03-04 Jason Merrill <jason@redhat.com>
PR c++/90432
* init.c (perform_member_init): Don't do aggregate initialization of
empty field.
* constexpr.c (cx_check_missing_mem_inits): Don't enforce
initialization of empty field.
Martin Sebor [Wed, 4 Mar 2020 22:14:49 +0000 (15:14 -0700)]
PR tree-optimization/93986 - ICE on mixed-precision wide_int arguments
gcc/testsuite/ChangeLog:
PR tree-optimization/93986
* gcc.dg/pr93986.c: New test.
gcc/ChangeLog:
PR tree-optimization/93986
* tree-ssa-strlen.c (maybe_warn_overflow): Convert all wide_int
operands to the same precision widest_int to avoid ICEs.
David Malcolm [Thu, 20 Feb 2020 13:44:23 +0000 (08:44 -0500)]
analyzer: validate region subclasses
This patch converts region::validate to a vfunc, implementing
additional checking per subclass: verifying that various
region_id fields within map_region, array_region, stack_region and
root_region are valid, rather than just those within the base class.
Doing so caught bugs earlier in follow-up work I have on
canonicalization and purging of region_model.
gcc/analyzer/ChangeLog:
* region-model.cc (region::validate): Convert model param from ptr
to reference. Update comment to reflect that it's now a vfunc.
(map_region::validate): New vfunc implementation.
(array_region::validate): New vfunc implementation.
(stack_region::validate): New vfunc implementation.
(root_region::validate): New vfunc implementation.
(region_model::validate): Pass a reference rather than a pointer
to the region::validate vfunc.
* region-model.h (region::validate): Make virtual. Convert model
param from ptr to reference.
(map_region::validate): New vfunc decl.
(array_region::validate): New vfunc decl.
(stack_region::validate): New vfunc decl.
(root_region::validate): New vfunc decl.
David Malcolm [Wed, 4 Mar 2020 17:10:34 +0000 (12:10 -0500)]
analyzer: add regression test for fixed ICE [PR94028]
The C++ reproducer for PR analyzer/94028 generates a similar ICE
to that of the Fortran reproducer for PR analyzer/93993 and, like
it, was fixed by
r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa.
This patch adds the C++ reproducer as a regression test.
gcc/testsuite/ChangeLog:
PR analyzer/94028
* g++.dg/analyzer/pr94028.C: New test.
Martin Sebor [Wed, 4 Mar 2020 17:23:49 +0000 (10:23 -0700)]
PR middle-end/81401 - false positive -Wformat-overflow in a loop
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/builtin-sprintf-warn-24.c: New test.
Will Schmidt [Wed, 4 Mar 2020 16:11:45 +0000 (10:11 -0600)]
Remove unnecessary XFAILs from existing testcase
20050603-3.c.
The XFAILs in this testcase (
20050603-3.c) are no longer necessary
since the fix to PR68803 was committed with svn revision r242681.
2020-03-04 Will Schmidt <will_schmidt@vnet.ibm.com>
testsuite
* gcc.target/powerpc/
20050603-3.c: Remove XFAILS.
Will Schmidt [Wed, 4 Mar 2020 16:05:17 +0000 (10:05 -0600)]
Add dg-require to existing powerpc/pr93122.c test
2020-03-04 Will Schmidt <will_schmidt@vnet.ibm.com>
* gcc.target/powerpc/pr93122.c: Add dg-require.
David Malcolm [Tue, 3 Mar 2020 21:36:13 +0000 (16:36 -0500)]
analyzer: handle __builtin_expect [PR93993]
The false warning:
pr93993.f90:19:0:
19 | allocate (tm) ! { dg-warning "dereference of possibly-NULL" }
|
Warning: dereference of possibly-NULL ‘_6’ [CWE-690] [-Wanalyzer-possible-null-dereference]
in the reproducer for PR analyzer/93993 is due to a BUILTIN_EXPECT in
the chain of SSA expressions between the malloc and the condition
guarding the edge: the analyzer didn't "know" about the relationship
between initial argument to BUILTIN_EXPECT and the return value.
This patch implements support for BUILTIN_EXPECT so that the return
value is known to be equal to the initial argument. This adds
constraints when exploring the CFG edges, eliminating the above
false positive.
Doing so also eliminated the leak warning from the reproducer. The
issue was that leaked_pvs was empty within
impl_region_model_context::on_state_leak, due to the leaking region
being a view, of type struct Pdtet_8 *, of a region of type
struct pdtet_8 *, which led region_model::get_representative_path_var to
return a NULL_TREE value.
Hence the patch also implements view support for
region_model::get_representative_path_var, restoring the leak
diagnostic, albeit changing the wording to:
Warning: leak of ‘(struct Pdtet_8) qb’ [CWE-401] [-Wanalyzer-malloc-leak]
It's not clear to me if we should emit leaks at a fortran "end program"
(currently we suppress them for leaks at the end of main).
gcc/analyzer/ChangeLog:
PR analyzer/93993
* region-model.cc (region_model::on_call_pre): Handle
BUILT_IN_EXPECT and its variants.
(region_model::add_any_constraints_from_ssa_def_stmt): Split out
gassign handling into add_any_constraints_from_gassign; add gcall
handling.
(region_model::add_any_constraints_from_gassign): New function,
based on the above. Add handling for NOP_EXPR.
(region_model::add_any_constraints_from_gcall): New function.
(region_model::get_representative_path_var): Handle views.
* region-model.h
(region_model::add_any_constraints_from_ssa_def_stmt): New decl.
(region_model::add_any_constraints_from_gassign): New decl.
gcc/testsuite/ChangeLog:
PR analyzer/93993
* gcc.dg/analyzer/expect-1.c: New test.
* gcc.dg/analyzer/malloc-4.c: New test.
* gfortran.dg/analyzer/pr93993.f90: Remove xfail from dg-bogus.
Move location of leak warning and update message.
David Malcolm [Tue, 3 Mar 2020 15:53:04 +0000 (10:53 -0500)]
analyzer: fix ICE on non-lvalue in prune_for_sm_diagnostic [PR93993]
PR analyzer/93993 reports another ICE within
diagnostic_manager::prune_for_sm_diagnostic in which the expression
of interest becomes a non-lvalue (similar to PR 93544, PR 93647, and
PR 93950), due to attempting to get an lvalue for a non-lvalue with a
NULL context, leading to an ICE when the failure is reported to
make_region_for_unexpected_tree_code. The tree in question is
an ADDR_EXPR of a VAR_DECL, due to:
event 11: switching var of interest from ‘tm’ in callee to ‘&qb’ in caller
This patch adds more bulletproofing to the routine by introducing
a tentative_region_model_context class that can be passed in such
circumstances which records that an error occurred, and then
checking to see if an error was recorded, thus avoiding the ICE.
This is papering over the problem, but a better solution seems more
like stage 1 material.
The patch also refactors the error-checking for CONSTANT_CLASS_P.
The testcase pr93993.f90 has a false positive:
pr93993.f90:19:0:
19 | allocate (tm) ! { dg-warning "dereference of possibly-NULL" }
|
Warning: dereference of possibly-NULL ‘_6’ [CWE-690] [-Wanalyzer-possible-null-dereference]
which appears to be a pre-existing bug affecting any allocate call in
Fortran, which I will fix in a followup.
gcc/analyzer/ChangeLog:
PR analyzer/93993
* checker-path.h (state_change_event::get_lvalue): Add ctxt param
and pass it to region_model::get_value call.
* diagnostic-manager.cc (get_any_origin): Pass a
tentative_region_model_context to the calls to get_lvalue and reject
the comparison if errors occur.
(can_be_expr_of_interest_p): New function.
(diagnostic_manager::prune_for_sm_diagnostic): Replace checks for
CONSTANT_CLASS_P with calls to update_for_unsuitable_sm_exprs.
Pass a tentative_region_model_context to the calls to
state_change_event::get_lvalue and reject the comparison if errors
occur.
(diagnostic_manager::update_for_unsuitable_sm_exprs): New.
* diagnostic-manager.h
(diagnostic_manager::update_for_unsuitable_sm_exprs): New decl.
* region-model.h (class tentative_region_model_context): New class.
gcc/testsuite/ChangeLog:
PR analyzer/93993
* gfortran.dg/analyzer/pr93993.f90: New test.
David Malcolm [Tue, 3 Mar 2020 21:45:56 +0000 (16:45 -0500)]
analyzer: remove unused private fields
gcc/analyzer/ChangeLog:
* engine.cc (worklist::worklist): Remove unused field m_eg.
(class viz_callgraph_edge): Remove unused field m_call_sedge.
(class viz_callgraph): Remove unused field m_sg.
* exploded-graph.h (worklist::::m_eg): Remove unused field.
Jonathan Wakely [Wed, 4 Mar 2020 15:34:05 +0000 (15:34 +0000)]
libstdc++: Fix comment on __memcpyable
The discussion of iterator_traits<volatile T*>::value_type and the
example with three tempalte arguments related to an earlier version of
the patch, not the one committed.
Also improve the comment on __memcmpable.
* include/bits/cpp_type_traits.h (__memcpyable): Fix comment.
Bill Schmidt [Wed, 4 Mar 2020 13:30:29 +0000 (07:30 -0600)]
rs6000: Fix -mpower9-vector -mno-altivec ICE (PR87560)
PR87560 reports an ICE when a test case is compiled with -mpower9-vector
and -mno-altivec. This patch terminates compilation with an error when
this combination (and other unreasonable ones) are requested.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Reported error is now:
f951: Error: '-mno-altivec' turns off '-mpower9-vector'
2020-03-02 Bill Schmidt <wschmidt@linux.ibm.com>
PR target/87560
* rs6000-cpus.def (OTHER_ALTIVEC_MASKS): New #define.
* rs6000.c (rs6000_disable_incompatible_switches): Add table entry
for OPTION_MASK_ALTIVEC.
Andreas Krebbel [Wed, 4 Mar 2020 12:29:39 +0000 (13:29 +0100)]
IBM Z: zTPF: Include glibc-stdint.h to get __UINTPTR_TYPE__ defined
Building a zTPF cross currently fails when building libstdc++
complaining about the __UINTPTR_TYPE__ to be missing.
Fixed by including the glibc-stdint.h header.
2020-03-04 Andreas Krebbel <krebbel@linux.ibm.com>
* config.gcc: Include the glibc-stdint.h header for zTPF.
Andreas Krebbel [Wed, 4 Mar 2020 12:29:39 +0000 (13:29 +0100)]
IBM Z: zTPF: Prevent FPR usage
For the zTPF we must not use floating point registers.
gcc/ChangeLog:
2020-03-04 Andreas Krebbel <krebbel@linux.ibm.com>
* config/s390/s390.c (s390_secondary_memory_needed): Disallow
direct FPR-GPR copies.
(s390_register_info_gprtofpr): Disallow GPR content to be saved in
FPRs.
Andreas Krebbel [Wed, 4 Mar 2020 12:29:38 +0000 (13:29 +0100)]
IBM Z: zTPF: Build libgcc with -mtpf-trace-skip
libgcc is supposed to be built with the trace skip flags and branch
targets. Add a zTPF header file fragment and add the -mtpf-trace-skip
option.
libgcc/ChangeLog:
2020-03-04 Andreas Krebbel <krebbel@linux.ibm.com>
* config.host: Include the new makefile fragment.
* config/s390/t-tpf: New file.
Andreas Krebbel [Wed, 4 Mar 2020 12:29:38 +0000 (13:29 +0100)]
IBM Z: zTPF: Add tpf trace customization options
The zTPF OS implements a tracing facility for function entry and exit
which uses global flags and trace function addresses. The addresses of
the flags as well as the trace functions are currently hard-coded in
the zTPF specific GCC parts of the IBM Z back-end.
With this patch these addresses can be changed at compile-time using
the new command line options. For convenience one additional command
line option (-mtpf-trace-skip) implements a new set of hard-coded
addresses.
gcc/ChangeLog:
2020-03-04 Andreas Krebbel <krebbel@linux.ibm.com>
* config/s390/s390.c (s390_emit_prologue): Specify the 2 new
operands to the prologue_tpf expander.
(s390_emit_epilogue): Likewise.
(s390_option_override_internal): Do error checking and setup for
the new options.
* config/s390/tpf.h (TPF_TRACE_PROLOGUE_CHECK)
(TPF_TRACE_EPILOGUE_CHECK, TPF_TRACE_PROLOGUE_TARGET)
(TPF_TRACE_EPILOGUE_TARGET, TPF_TRACE_PROLOGUE_SKIP_TARGET)
(TPF_TRACE_EPILOGUE_SKIP_TARGET): New macro definitions.
* config/s390/tpf.md ("prologue_tpf", "epilogue_tpf"): Add two new
operands for the check flag and the branch target.
* config/s390/tpf.opt ("mtpf-trace-hook-prologue-check")
("mtpf-trace-hook-prologue-target")
("mtpf-trace-hook-epilogue-check")
("mtpf-trace-hook-epilogue-target", "mtpf-trace-skip"): New
options.
* doc/invoke.texi: Document -mtpf-trace-skip option. The other
options are for debugging purposes and will not be documented
here.
Martin Liska [Wed, 4 Mar 2020 12:05:21 +0000 (13:05 +0100)]
Add -fcommon to a test-case to re-trigger it.
* gcc.target/i386/pr91623.c: Add -fcommon in order
to re-trigger the needed code for the test-case which
was added in
r10-2910-g9151048d854e352a9b83b771c6711b8221c73f7e.
Jakub Jelinek [Wed, 4 Mar 2020 11:59:04 +0000 (12:59 +0100)]
inliner: Copy DECL_BY_REFERENCE in copy_decl_to_var [PR93888]
In the following testcase we emit wrong debug info for the karg
parameter in the DW_TAG_inlined_subroutine into main.
The problem is that the karg PARM_DECL is DECL_BY_REFERENCE and thus
in the IL has const K & type, but in the source just const K.
When the function is inlined, we create a VAR_DECL for it, but don't
set DECL_BY_REFERENCE, so when emitting DW_AT_location, we treat it like
a const K & typed variable, but it has DW_AT_abstract_origin which has
just the const K type and thus the debugger thinks the variable has
const K type.
Fixed by copying the DECL_BY_REFERENCE flag. Not doing it in
copy_decl_for_dup_finish, because copy_decl_no_change already copies
that flag through copy_node and in copy_result_decl_to_var it is
undesirable, as we handle DECL_BY_REFERENCE in that case instead
by changing the type.
2020-03-04 Jakub Jelinek <jakub@redhat.com>
PR debug/93888
* tree-inline.c (copy_decl_to_var): Copy DECL_BY_REFERENCE flag.
* g++.dg/guality/pr93888.C: New test.
Jakub Jelinek [Wed, 4 Mar 2020 11:46:31 +0000 (12:46 +0100)]
sccvn: Avoid overflows in push_partial_def
The following patch attempts to avoid dangerous overflows in the various
push_partial_def HOST_WIDE_INT computations.
This is achieved by performing the subtraction offset2i - offseti in
the push_partial_def function and before doing that doing some tweaks.
If a constant store (non-CONSTRUCTOR) is too large (perhaps just
hypothetical case), native_encode_expr would fail for it, but we don't
necessarily need to fail right away, instead we can treat it like
non-constant store and if it is already shadowed, we can ignore it.
Otherwise, if it at most 64-byte and the caller ensured that there is
a range overlap and push_partial_def ensures the load is at most 64-byte,
I think we should be fine, offset (relative to the load)
can be from -64*8+1 to 64*8-1 only and size at most 64*8, so no risks of
overflowing HOST_WIDE_INT computations.
For CONSTRUCTOR (or non-constant) stores, those can be indeed arbitrarily
large, the caller just checks that both the absolute offset and size fit
into signed HWI. But, we store the same bytes in that case over and over
(both in the {} case where it is all 0, and in the hypothetical future case
where we handle in push_partial_def also memset (, 123, )), so we can tweak
the write range for our purposes. For {} store we could just cap it at the
start offset and/or offset+size because all the bits are 0, but I wrote it
in anticipation of the memset case and so the relative offset can now be
down to -7 and similarly size can grow up to 64 bytes + 14 bits, all this
trying to preserve the offset difference % BITS_PER_UNIT or end as well.
2020-03-04 Jakub Jelinek <jakub@redhat.com>
* tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): Add offseti
argument. Change pd argument so that it can be modified. Turn
constant non-CONSTRUCTOR store into non-constant if it is too large.
Adjust offset and size of CONSTRUCTOR or non-constant store to avoid
overflows.
(vn_walk_cb_data::vn_walk_cb_data, vn_reference_lookup_3): Adjust
callers.
Richard Biener [Wed, 4 Mar 2020 09:40:32 +0000 (10:40 +0100)]
tree-optimization/93964 - adjust ISL code generation for pointer params
Pointers eventually need intermediate conversions in code generation.
Allowing them is much easier than fending them off since niter
and scev expansion easily drag those in.
2020-02-04 Richard Biener <rguenther@suse.de>
PR tree-optimization/93964
* graphite-isl-ast-to-gimple.c
(gcc_expression_from_isl_ast_expr_id): Add intermediate
conversion for pointer to integer converts.
* graphite-scop-detection.c (assign_parameter_index_in_region):
Relax assert.
* gcc.dg/graphite/pr93964.c: New testcase.
Martin Liska [Wed, 4 Mar 2020 08:31:55 +0000 (09:31 +0100)]
Clear --help=language and --help=common interaction.
PR c/93886
PR c/93887
* doc/invoke.texi: Clarify --help=language and --help=common
interaction.
Martin Liska [Wed, 4 Mar 2020 08:31:05 +0000 (09:31 +0100)]
Wrap array in ctor with braces.
* method.c: Wrap array in ctor with braces in order
to silent clang warnings.
Jakub Jelinek [Wed, 4 Mar 2020 08:01:59 +0000 (09:01 +0100)]
tailcall: Fix up process_assignment [PR94001]
When a function returns void or the return value is ignored, ass_var
is NULL_TREE. The tail recursion handling generally assumes DCE has been
performed and so doesn't expect to encounter useless assignments after the
call and expects them to be part of the return value adjustment that need
to be changed into tail recursion additions/multiplications.
process_assignment does some verification and has a way to tell the caller
to try to move dead or whatever other stmts that don't participate in the
return value modifications before it is returned.
For binary rhs assignments it is just fine, neither op0 nor op1 will be
NULL_TREE and thus if *ass_var is NULL_TREE, it will not match, but unary
rhs is handled by only setting op0 to rhs1 and setting op1 to NULL_TREE.
And at this point, NULL_TREE == NULL_TREE and thus we think e.g. the
c_2 = -e_3(D);
dead stmt is actually a return value modification, so we queue it as
multiplication and then create a void type SSA_NAME accumulator for it
and ICE shortly after.
Fixed by making sure op1 == *ass_var comparison is done only if *ass_var.
2020-03-04 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/94001
* tree-tailcall.c (process_assignment): Before comparing op1 to
*ass_var, verify *ass_var is non-NULL.
* gcc.dg/pr94001.c: New test.
Kito Cheng [Tue, 3 Mar 2020 06:16:34 +0000 (14:16 +0800)]
PR target/93995 ICE in patch_jump_insn, at cfgrtl.c:1290 on riscv64-linux-gnu
Last code gen change of LTGT didn't consider the situation of cbranch with LTGT,
branch only support few compare codes.
gcc/ChangeLog
* config/riscv/riscv.c (riscv_emit_float_compare): Using NE to compare
the result of IOR.
gcc/testsuite/ChangeLog
* gcc.dg/pr93995.c: New.
Marek Polacek [Tue, 3 Mar 2020 22:56:44 +0000 (17:56 -0500)]
c++: Fix mismatch in template argument deduction [PR90505]
My GCC 9 patch for C++20 P0846R0 (ADL and function templates) tweaked
cp_parser_template_name to only return an identifier if name lookup
didn't find anything. In the deduce4.C case it means that we now
return an OVERLOAD. That means that cp_parser_template_id will call
lookup_template_function whereby producing a TEMPLATE_ID_EXPR with
unknown_type_node. Previously, we created a TEMPLATE_ID_EXPR with
no type, making it type-dependent. What we have now is no longer
type-dependent. And so, when we call finish_call_expr after we've
parsed "foo<int>(10)", even though we're in a template, we still do
the normal processing, thus perform overload resolution. When adding
the template candidate foo we need to deduce the template arguments,
and that is where things go downhill.
When fn_type_unification sees that we have explicit template arguments,
but they aren't complete, it will use them to substitute the function
type. So we substitute e.g. "void <T33d> (U)". But the explicit
template argument was for a different parameter so we don't actually
substitute anything. But the problem here was that we reduced the
template level of 'U' anyway. So then when we're actually deducing
the template arguments via type_unification_real, we fail in unify:
22932 if (TEMPLATE_TYPE_LEVEL (parm)
22933 != template_decl_level (tparm))
22934 /* The PARM is not one we're trying to unify. Just check
22935 to see if it matches ARG. */
because 'parm' has been reduced but 'tparm' has not yet.
Therefore we shouldn't reduce the template level of template parameters
when tf_partial aka template argument deduction substitution. But we
can only return after performing the cp_build_qualified_type etc.
business otherwise things break horribly.
2020-03-03 Jason Merrill <jason@redhat.com>
Marek Polacek <polacek@redhat.com>
PR c++/90505 - mismatch in template argument deduction.
* pt.c (tsubst): Don't reduce the template level of template
parameters when tf_partial.
* g++.dg/template/deduce4.C: New test.
* g++.dg/template/deduce5.C: New test.
* g++.dg/template/deduce6.C: New test.
* g++.dg/template/deduce7.C: New test.
Patrick Palka [Tue, 3 Mar 2020 21:16:05 +0000 (16:16 -0500)]
libstdc++: Fix incorrect use of memset in ranges::fill_n (PR 94017)
When deciding whether to perform the memset optimization in ranges::fill_n, we
were crucially neglecting to check that the output pointer's value type is a
byte type. This patch adds such a check to the problematic condition in
ranges::fill_n.
At the same time, this patch relaxes the overly conservative
__is_byte<_Tp>::__value check that requires the fill type be a byte type. It's
overly conservative because it means we won't enable the memset optimization in
the following example
char c[100];
ranges::fill(c, 37);
because the fill type is deduced to be int here. Rather than requiring that the
fill type be a byte type, it seems safe to just require the fill type be an
integral type, which is what this patch does.
libstdc++-v3/ChangeLog:
PR libstdc++/94017
* include/bits/ranges_algobase.h (__fill_n_fn::operator()): Refine
condition for when to use memset, making sure to additionally check that
the output pointer's value type is a non-volatile byte type. Instead of
requiring that the fill type is a byte type, just require that it's an
integral type.
* testsuite/20_util/specialized_algorithms/uninitialized_fill/94017.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_fill_n/94017.cc:
New test.
* testsuite/25_algorithms/fill/94013.cc: Uncomment part that was blocked
by PR 94017.
* testsuite/25_algorithms/fill/94017.cc: New test.
* testsuite/25_algorithms/fill_n/94017.cc: New test.
Patrick Palka [Tue, 3 Mar 2020 00:39:46 +0000 (19:39 -0500)]
libstdc++: Move-only input iterator support in <memory> algorithms (LWG 3355)
This adds support for move-only input iterators in the ranges::unitialized_*
algorithms defined in <memory>, as per LWG 3355. The only changes needed are to
add calls to std::move in the appropriate places and to use operator- instead of
ranges::distance because the latter cannot be used with a move-only iterator
that has a sized sentinel, as is the case here. (This issue with
ranges::distance is LWG 3392.)
libstdc++-v3/ChangeLog:
LWG 3355 The memory algorithms should support move-only input iterators
introduced by P1207
* include/bits/ranges_uninitialized.h
(__uninitialized_copy_fn::operator()): Use std::move to avoid attempting
to copy __ifirst, which could be a move-only input iterator. Use
operator- instead of ranges::distance to compute distance from a sized
sentinel.
(__uninitialized_copy_n_fn::operator()): Likewise.
(__uninitialized_move_fn::operator()): Likewise.
(__uninitialized_move_n_fn::operator()): Likewise.
(__uninitialized_destroy_fn::operator()): Use std::move to avoid
attempting to copy __first.
(__uninitialized_destroy_n_fn::operator()): Likewise.
* testsuite/20_util/specialized_algorithms/destroy/constrained.cc:
Augment test.
* .../specialized_algorithms/uninitialized_copy/constrained.cc:
Likewise.
* .../specialized_algorithms/uninitialized_move/constrained.cc:
Likewise.
Patrick Palka [Tue, 3 Mar 2020 03:32:22 +0000 (22:32 -0500)]
libstdc++: Add a testsuite range type that has a sized sentinel
This adds a testsuite range type whose end() is a sized sentinel to
<testsuite_iterators.h>, which will be used in the tests that verify LWG 3355.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_iterators.h (test_range::get_iterator): Make
protected instead of private.
(test_sized_range_sized_sent): New.
Patrick Palka [Mon, 2 Mar 2020 21:21:33 +0000 (16:21 -0500)]
libstdc++: Add a move-only testsuite iterator type
This adds a move-only testsuite iterator wrapper to <testsuite_iterators.h>
which will be used in the tests for LWG 3355. The tests for LWG 3389 and 3390
are adjusted to use this new iterator wrapper.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_iterators.h (input_iterator_wrapper_nocopy):
New testsuite iterator.
* testsuite/24_iterators/counted_iterator/lwg3389.cc: Use it.
* testsuite/24_iterators/move_iterator/lwg3390.cc: Likewise.
Patrick Palka [Tue, 3 Mar 2020 00:39:13 +0000 (19:39 -0500)]
libstdc++: Fix use of is_nothrow_assignable_v in <bits/ranges_uninitialized.h>
We are passing a value type as the first argument to is_nothrow_assignable_v,
but the result of that is inevitably false. Since this predicate is a part of
the condition that guards the corresponding optimizations for these algorithms,
this bug means these optimizations are never used. We should be passing a
reference type to is_nothrow_assignable_v instead.
libstdc++-v3/ChangeLog:
* include/bits/ranges_uninitialized.h
(uninitialized_copy_fn::operator()): Pass a reference type as the first
argument to is_nothrow_assignable_v.
(uninitialized_copy_fn::operator()): Likewise.
(uninitialized_move_fn::operator()): Likewise. Return an in_out_result
with the input iterator stripped of its move_iterator.
(uninitialized_move_n_fn::operator()): Likewise.
(uninitialized_fill_fn::operator()): Pass a reference type as the first
argument to is_nothrow_assignable_v.
(uninitialized_fill_n_fn::operator()): Likewise.
JunMa [Tue, 11 Feb 2020 08:01:08 +0000 (16:01 +0800)]
coroutines: Handle component_ref in captures_temporary
gcc/cp
* coroutines.cc (captures_temporary): Strip component_ref
to its base object.
gcc/testsuite
* g++.dg/coroutines/torture/co-await-15-capture-comp-ref.C: New test.
GCC Administrator [Wed, 4 Mar 2020 00:16:33 +0000 (00:16 +0000)]
Daily bump.
Jonathan Wakely [Tue, 3 Mar 2020 21:38:57 +0000 (21:38 +0000)]
libstdc++: Workaround is_trivially_copyable<volatile T> (PR 94013)
Several algorithms check the is_trivially_copyable trait to decide
whether to dispatch to memmove or memcmp as an optimization. Since
r271435 (CWG DR 2094) the trait is true for volatile-qualified scalars,
but we can't use memmove or memcmp when the type is volatile. We need to
also check for volatile types.
This is complicated by the fact that in C++20 (but not earlier standards)
iterator_traits<volatile T*>::value_type is T, so we can't just check
whether the value_type is volatile.
The solution in this patch is to introduce new traits __memcpyable and
__memcmpable which combine into a single trait the checks for pointers,
the value types being the same, and the type being trivially copyable
but not volatile-qualified.
PR libstdc++/94013
* include/bits/cpp_type_traits.h (__memcpyable, __memcmpable): New
traits to control when to use memmove and memcmp optimizations.
(__is_nonvolatile_trivially_copyable): New helper trait.
* include/bits/ranges_algo.h (__lexicographical_compare_fn): Do not
use memcmp optimization with volatile data.
* include/bits/ranges_algobase.h (__equal_fn): Use __memcmpable.
(__copy_or_move, __copy_or_move_backward): Use __memcpyable.
* include/bits/stl_algobase.h (__copy_move_a2): Use __memcpyable.
(__copy_move_backward_a2): Likewise.
(__equal_aux1): Use __memcmpable.
(__lexicographical_compare_aux): Do not use memcmp optimization with
volatile data.
* testsuite/25_algorithms/copy/94013.cc: New test.
* testsuite/25_algorithms/copy_backward/94013.cc: New test.
* testsuite/25_algorithms/equal/94013.cc: New test.
* testsuite/25_algorithms/fill/94013.cc: New test.
* testsuite/25_algorithms/lexicographical_compare/94013.cc: New test.
* testsuite/25_algorithms/move/94013.cc: New test.
* testsuite/25_algorithms/move_backward/94013.cc: New test.
Jakub Jelinek [Tue, 3 Mar 2020 18:49:12 +0000 (19:49 +0100)]
c++: Fix non-constant TARGET_EXPR constexpr handing [PR93998]
We ICE on the following testcase since I've added the SAVE_EXPR-like
constexpr handling where the TARGET_EXPR initializer (and cleanup) is
evaluated only once (because it might have side-effects like new or delete
expressions in it).
The problem is if the TARGET_EXPR (but I guess in theory SAVE_EXPR too)
initializer is *non_constant_p. We still remember the result, but already
not that it is *non_constant_p. Normally that wouldn't be a big problem,
if something is *non_constant_p, we only or into it and so the whole
expression will be non-constant too. Except in the builtins handling,
we try to evaluate the arguments with non_constant_p pointing into a dummy1
bool which we ignore. This is because some builtins might fold into a
constant even if they don't have a constexpr argument. Unfortunately if
we evaluate the TARGET_EXPR first in the argument of such a builtin and then
once again, we don't set *non_constant_p.
So, either we don't remember the TARGET_EXPR/SAVE_EXPR result if it wasn't
constant, like the following patch does, or we could remember it, but in
some way that would make it clear that it is non-constant (e.g. by
pushing into the global->values SAVE_EXPR, SAVE_EXPR entry and perhaps
for TARGET_EXPR don't remember it on TARGET_EXPR_SLOT, but the TARGET_EXPR
itself and similarly push TARGET_EXPR, TARGET_EXPR and if we see those
after the lookup, diagnose + set *non_constant_p. Or we could perhaps
during the builtin argument evaluation push expressions into a different
save_expr vec and undo them afterwards.
2020-03-03 Jakub Jelinek <jakub@redhat.com>
PR c++/93998
* constexpr.c (cxx_eval_constant_expression)
<case TARGET_EXPR, case SAVE_EXPR>: Don't record anything if
*non_constant_p is true.
* g++.dg/ext/pr93998.C: New test.
Richard Earnshaw [Tue, 3 Mar 2020 16:02:24 +0000 (16:02 +0000)]
libgcc: arm: convert thumb1 code to unified syntax
Unified syntax has been the official syntax for thumb1 assembly for
over 10 years now. It's time we made preparations for that becoming
the default in the assembler. But before we can start doing that we
really need to clean up some laggards from the olden days. Libgcc
support for thumb1 is one such example.
This patch converts all of the legacy (disjoint) syntax that I could
find over to unified code. The identification was done by using a
trick version of gas that defaulted to unified mode which then faults
if legacy syntax is encountered. The code produced was then compared
against the old code to check for differences. One such difference
does exist, but that is because in unified syntax 'movs rd, rn' is
encoded as 'lsls rd, rn, #0', rather than 'adds rd, rn, #0'; but that
is a deliberate change that was introduced because the lsls encoding
more closely reflects the behaviour of 'movs' in arm state (where only
some of the condition flags are modified).
* config/arm/bpabi-v6m.S (aeabi_lcmp): Convert thumb1 code to unified
syntax.
(aeabi_ulcmp, aeabi_ldivmod, aeabi_uldivmod): Likewise.
(aeabi_frsub, aeabi_cfcmpeq, aeabi_fcmpeq): Likewise.
(aeabi_fcmp, aeabi_drsub, aeabi_cdrcmple): Likewise.
(aeabi_cdcmpeq, aeabi_dcmpeq, aeabi_dcmp): Likewise.
* config/arm/lib1funcs.S (Lend_fde): Convert thumb1 code to unified
syntax.
(divsi3, modsi3): Likewise.
(clzdi2, ctzsi2): Likewise.
* config/arm/libunwind.S (restore_core_regs): Convert thumb1 code to
unified syntax.
(UNWIND_WRAPPER): Likewise.
Dennis Zhang [Tue, 3 Mar 2020 13:13:31 +0000 (13:13 +0000)]
arm: ACLE BFloat16 convert intrinsics
This patch is part of a series adding support for Armv8.6-A features.
It implements intrinsics to convert between bfloat16 and float32
formats.
gcc/ChangeLog:
* config/arm/arm_bf16.h (vcvtah_f32_bf16, vcvth_bf16_f32): New.
* config/arm/arm_neon.h (vcvt_f32_bf16, vcvtq_low_f32_bf16): New.
(vcvtq_high_f32_bf16, vcvt_bf16_f32): New.
(vcvtq_low_bf16_f32, vcvtq_high_bf16_f32): New.
* config/arm/arm_neon_builtins.def (vbfcvt, vbfcvt_high): New entries.
(vbfcvtv4sf, vbfcvtv4sf_high): Likewise.
* config/arm/iterators.md (VBFCVT, VBFCVTM): New mode iterators.
(V_bf_low, V_bf_cvt_m): New mode attributes.
* config/arm/neon.md (neon_vbfcvtv4sf<VBFCVT:mode>): New.
(neon_vbfcvtv4sf_highv8bf, neon_vbfcvtsf): New.
(neon_vbfcvt<VBFCVT:mode>, neon_vbfcvt_highv8bf): New.
(neon_vbfcvtbf_cvtmode<mode>, neon_vbfcvtbf): New
* config/arm/unspecs.md (UNSPEC_BFCVT, UNSPEC_BFCVT_HIG): New.
gcc/testsuite/ChangeLog:
* gcc.target/arm/simd/bf16_cvt_1.c: New test.
Jonathan Wakely [Tue, 3 Mar 2020 11:06:26 +0000 (11:06 +0000)]
libstdc++: Micro-optimisations for lexicographical_compare_three_way
As noted in LWG 3410 the specification in the C++20 draft performs more
iterator comparisons than necessary when the end of either range is
reached. Our implementation followed that specification. This removes
the redundant comparisons so that we do no unnecessary work as soon as
we find that we've reached the end of either range.
The odd-looking return statement is because it generates better code
than the original version that copied the global constants.
* include/bits/stl_algobase.h (lexicographical_compare_three_way):
Avoid redundant iterator comparisons (LWG 3410).
Jakub Jelinek [Tue, 3 Mar 2020 10:24:33 +0000 (11:24 +0100)]
sccvn: Improve handling of load masked with integer constant [PR93582]
As mentioned in the PR and discussed on IRC, the following patch is the
patch that fixes the originally reported issue.
We have there because of the premature bitfield comparison -> BIT_FIELD_REF
optimization:
s$s4_19 = 0;
s.s4 = s$s4_19;
_10 = BIT_FIELD_REF <s, 8, 0>;
_13 = _10 & 8;
and no other s fields are initialized. If they would be all initialized with
constants, then my earlier PR93582 bitfield handling patches would handle it
already, but if at least one bit we ignore after the BIT_AND_EXPR masking
is not initialized or is initialized earlier to non-constant, we aren't able
to look through it until combine, which is too late for the warnings on the
dead code.
This patch handles BIT_AND_EXPR where the first operand is a SSA_NAME
initialized with a memory load and second operand is INTEGER_CST, by trying
a partial def lookup after pushing the ranges of 0 bits in the mask as
artificial initializers. In the above case on little-endian, we push
offset 0 size 3 {} partial def and offset 4 size 4 (the result is unsigned
char) and then perform normal partial def handling.
My initial version of the patch failed miserably during bootstrap, because
data->finish (...) called vn_reference_lookup_or_insert_for_pieces
which I believe tried to remember the masked value rather than real for the
reference, or for failed lookup visit_reference_op_load called
vn_reference_insert. The following version makes sure we aren't calling
either of those functions in the masked case, as we don't know anything
better about the reference from whatever has been discovered when the load
stmt has been visited, the patch just calls vn_nary_op_insert_stmt on
failure with the lhs (apparently calling it with the INTEGER_CST doesn't
work).
2020-03-03 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/93582
* tree-ssa-sccvn.h (vn_reference_lookup): Add mask argument.
* tree-ssa-sccvn.c (struct vn_walk_cb_data): Add mask and masked_result
members, initialize them in the constructor and if mask is non-NULL,
artificially push_partial_def {} for the portions of the mask that
contain zeros.
(vn_walk_cb_data::finish): If mask is non-NULL, set masked_result to
val and return (void *)-1. Formatting fix.
(vn_reference_lookup_pieces): Adjust vn_walk_cb_data initialization.
Formatting fix.
(vn_reference_lookup): Add mask argument. If non-NULL, don't call
fully_constant_vn_reference_p nor vn_reference_lookup_1 and return
data.mask_result.
(visit_nary_op): Handle BIT_AND_EXPR of a memory load and INTEGER_CST
mask.
(visit_stmt): Formatting fix.
* gcc.dg/tree-ssa/pr93582-10.c: New test.
* gcc.dg/pr93582.c: New test.
* gcc.c-torture/execute/pr93582.c: New test.
Richard Biener [Tue, 3 Mar 2020 10:01:09 +0000 (11:01 +0100)]
tree-optimization/93946 - fix bogus redundant store removal in FRE, DSE and DOM
This fixes a common mistake in removing a store that looks redudnant but
is not because it changes the dynamic type of the memory and thus makes
a difference for following loads with TBAA.
2020-03-03 Richard Biener <rguenther@suse.de>
PR tree-optimization/93946
* alias.h (refs_same_for_tbaa_p): Declare.
* alias.c (refs_same_for_tbaa_p): New function.
* tree-ssa-alias.c (ao_ref_alias_set): For a NULL ref return
zero.
* tree-ssa-scopedtables.h
(avail_exprs_stack::lookup_avail_expr): Add output argument
giving access to the hashtable entry.
* tree-ssa-scopedtables.c (avail_exprs_stack::lookup_avail_expr):
Likewise.
* tree-ssa-dom.c: Include alias.h.
(dom_opt_dom_walker::optimize_stmt): Validate TBAA state before
removing redundant store.
* tree-ssa-sccvn.h (vn_reference_s::base_set): New member.
(ao_ref_init_from_vn_reference): Adjust prototype.
(vn_reference_lookup_pieces): Likewise.
(vn_reference_insert_pieces): Likewise.
* tree-ssa-sccvn.c: Track base alias set in addition to alias
set everywhere.
(eliminate_dom_walker::eliminate_stmt): Also check base alias
set when removing redundant stores.
(visit_reference_op_store): Likewise.
* dse.c (record_store): Adjust valdity check for redundant
store removal.
* gcc.dg/torture/pr93946-1.c: New testcase.
* gcc.dg/torture/pr93946-2.c: Likewise.
Jakub Jelinek [Tue, 3 Mar 2020 09:44:24 +0000 (10:44 +0100)]
s390: Fix --with-arch=... --with-tune=... [PR26877]
In Fedora we configure GCC with --with-arch=zEC12 --with-tune=z13 right now
and furthermore redhat-rpm-config adds to rpm packages -march=zEC12 -mtune=z13
options (among others). While looking at the git compilation, I've been
surprised that -O2 actually behaves differently from -O2 -mtune=z13 in this
configuration, and indeed, seems --with-tune= is completely ignored on s390
if --with-arch= is specified.
i386 had the same problem, but got that fixed in 2006, see PR26877.
The thing is that for tune, we add -mtune=%(VALUE) only if neither -mtune=
nor -march= is present, but as arch is processed first, it adds
-march=%(VALUE) first and then -march= is always present and so -mtune= is
never added.
By reordering it in OPTION_DEFAULT_SPECS, we process tune first, add the
default -mtune=%(VALUE) if -mtune= or -march= isn't seen, and then
add -march=%(VALUE) if -march= isn't seen. It is true that cc1 etc.
will be then invoked with -mtune=z13 -march=zEC12, but like if the user
specifies it in that order, it should still use z13 tuning and zEC12
ISA set.
2020-03-03 Jakub Jelinek <jakub@redhat.com>
PR target/26877
* config/s390/s390.h (OPTION_DEFAULT_SPECS): Reorder.
Jakub Jelinek [Tue, 3 Mar 2020 09:42:34 +0000 (10:42 +0100)]
explow: Fix ICE caused by plus_constant [PR94002]
The following testcase ICEs in cross to riscv64-linux. The problem is
that we have a DImode integral constant (that doesn't fit into SImode),
which is pushed into a constant pool and later access just the first half of
it using a MEM. When plus_constant is called on such a MEM, if the constant
has mode, we verify the mode, but if it doesn't, we don't and ICE later on
when we think the CONST_INT is a valid SImode constant.
2020-03-03 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/94002
* explow.c (plus_constant): Punt if cst has VOIDmode and
get_pool_mode is different from mode.
* gcc.dg/pr94002.c: New test.
Claudiu Zissulescu [Tue, 3 Mar 2020 08:34:50 +0000 (10:34 +0200)]
arc: Update legitimate small data address.
All ARC's small data adressing is using address scaling feature of the
load/store instructions (i.e., the address is made of a general
pointer plus a shifted offset. The shift amount depends on the
addressing mode). This patch is checking the offset of an address if
it fits the scalled constraint. If so, a small data access is
generated. This patch fixes execute' pr93249 failure.
gcc/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* config/arc/arc.c (leigitimate_small_data_address_p): Check if an
address has an offset which fits the scalling constraint for a
load/store operation.
(legitimate_scaled_address_p): Update use
leigitimate_small_data_address_p.
(arc_print_operand): Likewise.
(arc_legitimate_address_p): Likewise.
(legitimate_small_data_address_p): Likewise.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
Claudiu Zissulescu [Tue, 3 Mar 2020 08:34:50 +0000 (10:34 +0200)]
arc: Use accl_operand predicate for fma instructions.
With the refurbish of ARC600' accumulator support, the mlo_operand
doesn't reflect the proper low accumulator register for the newer
ARCv2 accumulator register used by the fma instructions. Hence,
replace it with accl_operand predicate.
gcc/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* config/arc/arc.md (fmasf4_fpu): Use accl_operand predicate.
(fnmasf4_fpu): Likewise.
Claudiu Zissulescu [Tue, 3 Mar 2020 08:34:50 +0000 (10:34 +0200)]
arc: Improve code gen for 64bit add/sub operations.
Early expand ADDDI3 and SUBDI3 for better code gen.
gcc/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* config/arc/arc.md (adddi3): Early expand the 64bit operation into
32bit ops.
(subdi3): Likewise.
(adddi3_i): Remove pattern.
(subdi3_i): Likewise.
Claudiu Zissulescu [Tue, 3 Mar 2020 08:34:49 +0000 (10:34 +0200)]
arc: Add length attribute to eh_return pattern.
gcc/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* config/arc/arc.md (eh_return): Add length info.
Jakub Jelinek [Tue, 3 Mar 2020 06:58:12 +0000 (07:58 +0100)]
testsuite: Add testcases for already fixed PR [PR93927]
2020-03-03 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/93927
* gcc.c-torture/compile/pr93927-1.c: New test.
* gcc.c-torture/compile/pr93927-2.c: New test.
JunMa [Wed, 5 Feb 2020 05:46:59 +0000 (13:46 +0800)]
Build coroutine expression with unknown_type in processing_template_decl phase.
gcc/cp
* coroutines.cc (finish_co_await_expr): Build co_await_expr
with unknown_type_node.
(finish_co_yield_expr): Ditto.
*pt.c (type_dependent_expression_p): Set co_await/yield_expr
with unknown type as dependent.
gcc/testsuite
* g++.dg/coroutines/torture/co-await-14-template-traits.C: New test.
GCC Administrator [Tue, 3 Mar 2020 00:16:38 +0000 (00:16 +0000)]
Daily bump.
David Malcolm [Fri, 28 Feb 2020 15:06:57 +0000 (10:06 -0500)]
analyzer: don't print the duplicate count by default
The note about duplicates attached to analyzer diagnostics feels like an
implementation detail; it's likely just noise from the perspective of an
end-user.
This patch disables it by default, introducing a flag to re-enable it.
gcc/analyzer/ChangeLog:
* analyzer.opt (fanalyzer-show-duplicate-count): New option.
* diagnostic-manager.cc
(diagnostic_manager::emit_saved_diagnostic): Use the above to
guard the printing of the duplicate count.
gcc/ChangeLog:
* doc/invoke.texi (-fanalyzer-show-duplicate-count): New.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/CVE-2005-1689-dedupe-issue.c: Add
-fanalyzer-show-duplicate-count.
David Malcolm [Fri, 28 Feb 2020 13:55:55 +0000 (08:55 -0500)]
invoke.texi: add missing option to -fanalyzer list
gcc/ChangeLog:
* doc/invoke.texi (Static Analyzer Options): Add
-Wanalyzer-stale-setjmp-buffer to the list of options enabled
by -fanalyzer.
David Malcolm [Thu, 27 Feb 2020 19:19:33 +0000 (14:19 -0500)]
analyzer: detect malloc, free, calloc within "std" [PR93959]
PR analyzer/93959 reported that g++.dg/analyzer/malloc.C was failing
with no output on Solaris.
The issue is that <stdlib.h> there has "using std::free;", converting
all the "free" calls to std::free, which fails the name-matching via
is_named_call_p.
This patch implements an is_std_named_call_p variant of is_named_call_p
to check for the name within "std", and uses it in sm-malloc.c to check
for std::malloc, std::calloc, and std::free.
gcc/analyzer/ChangeLog:
PR analyzer/93959
* analyzer.cc (is_std_function_p): New function.
(is_std_named_call_p): New functions.
* analyzer.h (is_std_named_call_p): New decl.
* sm-malloc.cc (malloc_state_machine::on_stmt): Check for "std::"
variants when checking for malloc, calloc and free.
gcc/testsuite/ChangeLog:
PR analyzer/93959
* g++.dg/analyzer/cstdlib-2.C: New test.
* g++.dg/analyzer/cstdlib.C: New test.
Iain Sandoe [Mon, 2 Mar 2020 20:29:32 +0000 (20:29 +0000)]
coroutines: Update lambda capture handling to n4849.
In the absence of specific comment on the handling of closures I'd
implemented something more than was intended (extending the lifetime
of lambda capture-by-copy vars to the duration of the coro).
After discussion at WG21 in February and by email, the correct handling
is to treat the closure "this" pointer the same way as for a regular one,
and thus it is the user's responsibility to ensure that the lambda capture
object has suitable lifetime for the coroutine. It is noted that users
frequently get this wrong, so it would be a good thing to revisit for C++23.
This patch removes the additional copying behaviour for lambda capture-by-
copy vars.
gcc/cp/ChangeLog:
2020-03-02 Iain Sandoe <iain@sandoe.co.uk>
* coroutines.cc (struct local_var_info): Adjust to remove the
reference to the captured var, and just to note that this is a
lambda capture proxy.
(transform_local_var_uses): Handle lambda captures specially.
(struct param_frame_data): Add a visited set.
(register_param_uses): Also check for param uses in lambda
capture proxies.
(struct local_vars_frame_data): Remove captures list.
(register_local_var_uses): Handle lambda capture proxies by
noting and bypassing them.
(morph_fn_to_coro): Update to remove lifetime extension of
lambda capture-by-copy vars.
gcc/testsuite/ChangeLog:
2020-03-02 Iain Sandoe <iain@sandoe.co.uk>
Jun Ma <JunMa@linux.alibaba.com>
* g++.dg/coroutines/torture/class-05-lambda-capture-copy-local.C:
* g++.dg/coroutines/torture/lambda-09-init-captures.C: New test.
* g++.dg/coroutines/torture/lambda-10-mutable.C: New test.
Uros Bizjak [Mon, 2 Mar 2020 20:13:36 +0000 (21:13 +0100)]
i386: Allow only registers with VALID_INT_MODE_P modes in movstrict<mode> [PR93997]
*movstrict<mode>_1 insn pattern allows only general registers,
so we have to reject modes not suitable for general regs in
corresponding movstrict<mode> expander.
PR target/93997
* config/i386/i386.md (movstrict<mode>): Allow only
registers with VALID_INT_MODE_P modes.
testsuite/ChangeLog:
PR target/93997
* gcc.target/i386/pr93997.c: New test.
Martin Sebor [Mon, 2 Mar 2020 18:49:01 +0000 (11:49 -0700)]
Add new test for PR tree-optimization/92982.
gcc/testsuite/ChangeLog:
PR tree-optimization/92982
* gcc.dg/strlenopt-94.c: New test.
Marek Polacek [Sat, 29 Feb 2020 19:50:19 +0000 (14:50 -0500)]
c++: Add -std=gnu++20 option [PR93958]
One missing bit from r10-6656. The docs and target-supports.exp
already handle -std=gnu++20.
2020-03-02 Marek Polacek <polacek@redhat.com>
PR c++/93958 - add missing -std=gnu++20.
* c.opt: Add -std=gnu++20.
Andrew Benson [Mon, 2 Mar 2020 17:28:35 +0000 (17:28 +0000)]
Ensure sufficient size of variables used for module+submodule names.
PR fortran/93486
* module.c: Increase size of variables used to read module names
when loading interfaces from module files to permit cases where
the name is the concatenation of a module and submodule name.
* gfortran.dg/pr93486.f90: New test.
Jonathan Wakely [Mon, 2 Mar 2020 17:03:28 +0000 (17:03 +0000)]
libstdc++: Fix std::lexicographic_compare for unsigned char (PR 93972)
The new 25_algorithms/lexicographical_compare/93972.cc test fails on
targets where char is unsigned, revealing an existing regression with
the std::__memcmp helper that had gone unnoticed in
std::lexicographical_compare. When comparing char and unsigned char, the
memcmp optimisation is enabled, but the new std::__memcmp function fails
to compile for mismatched types.
PR libstdc++/93972
* include/bits/stl_algobase.h (__memcmp): Allow pointer types to
differ.
* testsuite/25_algorithms/lexicographical_compare/uchar.cc: New test.
Jonathan Wakely [Mon, 2 Mar 2020 17:03:28 +0000 (17:03 +0000)]
libstdc++: Rename __detail::__maybe_empty_t alias template
The key property of this alias is not that it may be an empty type, but
that the type argument may not be used. The fact it's replaced by an
empty type is just an implementation detail. The name was also
backwards with respect to the bool argument.
This patch changes the name to better reflect its purpose.
* include/std/ranges (__detail::__maybe_empty_t): Rename to
__maybe_present_t.
(__adaptor::_RangeAdaptor, join_view, split_view): Use new name.
Iain Sandoe [Mon, 2 Mar 2020 15:35:45 +0000 (15:35 +0000)]
coroutines: Don't make duplicate frame copies of awaitables.
In general, we need to manage the lifetime of compiler-
generated awaitable instances in the coroutine frame, since
these must persist across suspension points.
However, it is quite possible that the user might provide the
awaitable instances, either as function params or as a local
variable. We will already generate a frame entry for these as
required.
At present, under this circumstance, we are duplicating these,
awaitable, initialising a second frame copy for them (which we
then subsequently destroy manually after the suspension point).
That's not efficient - so an undesirable thinko in the first place.
However, there is also an actual bug; if the compiler elects to
elide the copy (which is perfectly legal), it does not have visibility
of the manual management of the post-suspend destruction
- this subsequently leads to double-free errors.
The solution is not to make the second copy (as noted, params
and local vars already have frame copies with managed lifetimes).
gcc/cp/ChangeLog:
2020-03-02 Iain Sandoe <iain@sandoe.co.uk>
* coroutines.cc (build_co_await): Do not build frame
proxy vars when the co_await expression is a function
parameter or local var.
(co_await_expander): Do not initialise a frame var with
itself.
(transform_await_expr): Only substitute the awaitable
frame var if it's needed.
(register_awaits): Do not make frame copies for param
or local vars that are awaitables.
gcc/testsuite/ChangeLog:
2020-03-02 Iain Sandoe <iain@sandoe.co.uk>
* g++.dg/coroutines/torture/func-params-09-awaitable-parms.C: New test.
* g++.dg/coroutines/torture/local-var-5-awaitable.C: New test.
Andrew Stubbs [Fri, 7 Feb 2020 11:14:43 +0000 (11:14 +0000)]
amdgcn: Extend reductions to all types
Add support for V64DFmode addition, and V64DImode min, max. There's no
direct hardware support for these, so we use regular vector instructions
and separate lane shift instructions.
Also add support for V64QI and V64HI reductions. Some of these require
additional extends and truncates, because AMD GCN has 32-bit vector lanes.
2020-03-02 Andrew Stubbs <ams@codesourcery.com>
gcc/
* config/gcn/gcn-valu.md (dpp_move<mode>): New.
(reduc_insn): Use 'U' and 'B' operand codes.
(reduc_<reduc_op>_scal_<mode>): Allow all types.
(reduc_<reduc_op>_scal_v64di): Delete.
(*<reduc_op>_dpp_shr_<mode>): Allow all 1reg types.
(*plus_carry_dpp_shr_v64si): Change to ...
(*plus_carry_dpp_shr_<mode>): ... this and allow all 1reg int types.
(mov_from_lane63_v64di): Change to ...
(mov_from_lane63_<mode>): ... this, and allow all 64-bit modes.
* config/gcn/gcn.c (gcn_expand_dpp_shr_insn): Increase buffer size.
Support UNSPEC_MOV_DPP_SHR output formats.
(gcn_expand_reduc_scalar): Add "use_moves" reductions.
Add "use_extends" reductions.
(print_operand_address): Add 'I' and 'U' codes.
* config/gcn/gcn.md (unspec): Add UNSPEC_MOV_DPP_SHR.
Jeff Law [Mon, 2 Mar 2020 15:44:28 +0000 (08:44 -0700)]
Fix testsuite regression due to recent IRA changes.
* gcc.target/arm/fuse-caller-save.c: Update expected output.
Segher Boessenkool [Mon, 2 Mar 2020 13:24:20 +0000 (13:24 +0000)]
Fix changelog typo
Jonathan Wakely [Mon, 2 Mar 2020 12:18:45 +0000 (12:18 +0000)]
libstdc++: Add 'typename' to fix compilation with Clang
* include/bits/ranges_algo.h (shift_right): Add 'typename' to
dependent type.
Martin Liska [Mon, 2 Mar 2020 12:11:56 +0000 (13:11 +0100)]
Update comment to reflect optimization.
* gcc.dg/vect/bb-slp-19.c: The comment
does not align with fact that we started
to SLP the testcase.
Martin Liska [Mon, 2 Mar 2020 12:08:49 +0000 (13:08 +0100)]
Remove duplicate declaration.
* libgcov-interface.c: Remove duplicate
declaration of __gcov_flush_mx.
Nick Clifton [Mon, 2 Mar 2020 11:50:34 +0000 (03:50 -0800)]
Fix a libiberty testsuite failure
* testsuite/demangle-expected: Update expected demangling of
enable_if pattern.
H.J. Lu [Mon, 2 Mar 2020 11:08:57 +0000 (03:08 -0800)]
lto: Also copy .note.gnu.property section
When generating the separate file with LTO debug sections, we should
also copy .note.gnu.property section.
PR lto/93966
* simple-object.c (handle_lto_debug_sections): Also copy
.note.gnu.property section.
Martin Liska [Mon, 2 Mar 2020 10:05:02 +0000 (11:05 +0100)]
Fix typo in C++ standard version.
* lto-wrapper.c: Fix typo in comment about
C++ standard version.
Kewen Lin [Mon, 2 Mar 2020 09:36:30 +0000 (03:36 -0600)]
[testsuites] Update several scev/IVOPTs cases
Several scev/IVOPTs cases aim to check some array references are sceved and
later marked as REFERENCE ADDRESS IV groups. With IV group type dumping
improving, these check strings can be improved. Otherwise, they become fragile
with dumping changes.
This patch is to keep check strings concise, meanwhile recover the coverage of
case scev-8.c.
gcc/testsuite/ChangeLog
2020-03-02 Kewen Lin <linkw@gcc.gnu.org>
* gcc.dg/tree-ssa/scev-8.c: Revise check string.
* gcc.dg/tree-ssa/scev-9.c: Ditto.
* gcc.dg/tree-ssa/scev-10.c: Ditto.
* gcc.dg/tree-ssa/scev-11.c: Ditto.
* gcc.dg/tree-ssa/scev-12.c: Ditto.
Martin Sebor [Mon, 2 Mar 2020 00:58:45 +0000 (17:58 -0700)]
PR middle-end/92721 - checking ICE on attribute access redeclaration
gcc/c-family/ChangeLog:
PR c++/92721
* c-attribs.c (append_access_attrs): Correctly handle attribute.
(handle_access_attribute): Same.
gcc/ChangeLog:
PR c++/92721
* calls.c (init_attr_rdwr_indices): Correctly handle attribute.
gcc/testsuite/ChangeLog:
PR c++/92721
g++.dg/ext/attr-access.C: New test.
Martin Sebor [Mon, 2 Mar 2020 00:52:44 +0000 (17:52 -0700)]
PR middle-end/93926 - ICE on a built-in redeclaration returning an integer instead of a pointer
gcc/c/ChangeLog:
PR middle-end/93926
* c-decl.c (types_close_enough_to_match): New function.
(match_builtin_function_types):
(diagnose_mismatched_decls): Add missing inform call to a warning.
gcc/testsuite/ChangeLog:
PR middle-end/93926
* gcc.dg/Wbuiltin-declaration-mismatch-13.c: New test.
Martin Sebor [Mon, 2 Mar 2020 00:41:45 +0000 (17:41 -0700)]
PR c/93812 - ICE on redeclaration of an attribute format function without protoype
gcc/c/ChangeLog:
PR c/93812
* c-typeck.c (build_functype_attribute_variant): New function.
(composite_type): Call it.
gcc/testsuite/ChangeLog:
PR c/93812
* gcc.dg/format/proto.c: New test.
Martin Sebor [Mon, 2 Mar 2020 00:35:49 +0000 (17:35 -0700)]
PR middle-end/93829 - bogus -Wstringop-overflow on memcpy of a struct with a pointer member from another with a long string
gcc/testsuite/ChangeLog:
PR middle-end/93829
* gcc.dg/Wstringop-overflow-32.c: New test.
gcc/ChangeLog:
PR middle-end/93829
* tree-ssa-strlen.c (count_nonzero_bytes): Set the size to that
of a pointer in the outermost ADDR_EXPRs.
GCC Administrator [Mon, 2 Mar 2020 00:16:33 +0000 (00:16 +0000)]
Daily bump.
Segher Boessenkool [Sun, 1 Mar 2020 18:17:30 +0000 (11:17 -0700)]
Fix test for pr68805.
PR testsuite/91797
* gcc.target/pwoerpc/pr68805.c: Update expected output.