The following testcase started to ICE when .POPCOUNT matching has been added
to match.pd; we had __builtin_popcount*, but nothing would use the
popcounthi2 expander before.
The problem is that the popcounthi2_z196 expander doesn't emit valid RTL:
error: unrecognizable insn:
(insn 138 137 139 27 (set (reg:SI 190)
(ashift:SI (reg:HI 95 [ _105 ])
(const_int 8 [0x8]))) -1
(nil))
during RTL pass: vregs
The following patch is an attempt to fix that, furthermore I've tried to
slightly simplify it as well, it makes no sense to me to perform
(x + (x << 8)) >> 8 when we need to either zero extend or mask the result
at the end in order to avoid bits from above HImode to affect it, when we
can do
(x + (x >> 8)) & 0xff (or zero extension).
2020-02-03 Jakub Jelinek <jakub@redhat.com>
PR target/93533
* config/s390/s390.md (popcounthi2_z196): Fix up expander to emit
valid RTL to sum up the lowest and second lowest bytes of the popcnt
result.
* gcc.c-torture/compile/pr93533.c: New test.
* gcc.target/s390/pr93533.c: New test.
gcc/cp
* coroutines.cc (transform_await_wrapper): Set actor funcion as
new context of label_decl.
(build_actor_fn): Fill new field of await_xform_data.
gcc/testsuite
* g++.dg/coroutines/co-await-04-control-flow.C: Add label.
This fixes an ICE taking place in cp_default_conversion because we got
a SCOPE_REF that doesn't have a type and so checking
INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (TREE_TYPE (exp)) will crash.
This happens since the recent Joseph's change in decl_attributes whereby
we don't skip C++11 attributes on types.
[dcl.align] is clear that alignas applied to a function is ill-formed.
That should be fixed, and we have PR90847 for that. But I think a more
appropriate fix at this stage would be the following: in a template we
want to splice dependent attributes and save them for later, and by
doing so avoid this crash.
PR c++/93530 - ICE on invalid alignas in a template.
* decl.c (grokdeclarator): Call cplus_decl_attributes instead of
decl_attributes.
* g++.dg/cpp0x/alignas18.C: New test.
This test explicitly tests for code generation that expects a
common section.
gcc/testsuite/ChangeLog:
2020-02-02 Iain Sandoe <iain@sandoe.co.uk>
* gcc.target/powerpc/darwin-abi-12.c: Add '-fcommon' to the
options.
2020-02-02 Vladimir Makarov <vmakarov@redhat.com>
PR rtl-optimization/91333
* ira-color.c (struct allocno_color_data): Add member
hard_reg_prefs.
(init_allocno_threads): Set the member up.
(bucket_allocno_compare_func): Add compare hard reg
prefs.
2020-02-02 Vladimir Makarov <vmakarov@redhat.com>
PR rtl-optimization/91333
* gcc.target/i386/pr91333.c: Add vmovsd to regexp. Set up count
to 3.
The following patch fixes
-FAIL: libgomp.fortran/use_device_addr-1.f90 -O0 execution test
-FAIL: libgomp.fortran/use_device_addr-2.f90 -O0 execution test
that has been FAILing for several months on powerpc64le-linux.
The problem is in the Fortran FE, which adds the artificial arguments
for scalar VALUE OPTIONAL dummy args only to DECL_ARGUMENTS where the
current function can see them, but not to TYPE_ARG_TYPES; if those functions
aren't varargs, this confuses calls.c to pass the remaining arguments
(which aren't named (== not covered by TYPE_ARG_TYPES) and aren't varargs
either) in a different spot from what the callee (which has proper
DECL_ARGUMENTS for all args) expects. For the artificial length arguments
for character dummy args we already put them in both DECL_ARGUMENTS and
TYPE_ARG_TYPES.
2020-02-01 Jakub Jelinek <jakub@redhat.com>
PR fortran/92305
* trans-types.c (gfc_get_function_type): Also push boolean_type_node
types for non-character scalar VALUE optional dummy arguments.
* trans-decl.c (create_function_arglist): Skip those in
hidden_typelist. Formatting fix.
On nios2-linux-gnu, there has been a long-standing bug in C++ exception
handling that sometimes resulted in link errors like
../nios2-linux-gnu/bin/ld: FDE encoding in /tmp/cccfpQ2l.o(.eh_frame) prevents .eh_frame_hdr table being created
when building some shared libraries or PIE executables. The root of
the problem is that GCC was incorrectly emitting an absolute encoding
in EH tables for PIC. This patch changes it to use either
DW_EH_PE_indirect (for global) or DW_EH_PE_datarel (for local), and
fixes libgcc so it can find the address of the GOT as the base address
for DW_EH_PE_datarel.
Complicating matters somewhat, GAS was missing support for
%gotoff(symbol) relocation syntax. I have just pushed a fix for that,
but I've added a configure check to test for presence of the binutils
support and fall back to the current absolute encoding (which works
most of the time) if it is not available. Once the fix makes it into
an official binutils release it might be appropriate to make this
error out instead.
Since this is a wrong-code bug and affects only nios2 target, I think
this is appropriate for Stage 4. I regression-tested on both
nios2-linux-gnu and nios2-elf, with and without the binutils support
present, before committing this.
2020-01-31 Sandra Loosemore <sandra@codesourcery.com>
gcc/
* configure.ac [nios2-*-*]: Check HAVE_AS_NIOS2_GOTOFF_RELOCATION.
* config.in: Regenerated.
* configure: Regenerated.
* config/nios2/nios2.h (ASM_PREFERRED_EH_DATA_FORMAT): Fix handling
for PIC when HAVE_AS_NIOS2_GOTOFF_RELOCATION.
(ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX): New.
gcc/testsuite/
* g++.target/nios2/hello-pie.C: New.
* g++.target/nios2/nios2.exp: New.
libgcc/
* config.host [nios2-*-linux*] (tmake_file, tm_file): Adjust.
* config/nios2-elf-lib.h: New.
* unwind-dw2-fde-dip.c (_Unwind_IteratePhdrCallback): Use existing
code for finding GOT base for nios2.
This commit:
commit e7c26e04b2 (tjteru/master)
Date: Wed Jan 22 14:54:26 2020 +0000
gcc: Add new configure options to allow static libraries to be selected
contains a couple of issues. First I failed to correctly regenerate
all of the configure files it should have done. Second, there was a
mistake in lib-link.m4, one of the conditions didn't use pure sh
syntax, I wrote this:
if x$lib_type = xauto || x$lib_type = xshared; then
When I should have written this:
if test "x$lib_type" = "xauto" || test "x$lib_type" = "xshared"; then
These issues were raised on the mailing list in these messages:
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01827.htmlhttps://gcc.gnu.org/ml/gcc-patches/2020-01/msg01921.html
config/ChangeLog:
* lib-link.m4 (AC_LIB_LINKFLAGS_BODY): Update shell syntax.
gcc/ChangeLog:
* configure: Regenerate.
intl/ChangeLog:
* configure: Regenerate.
libcpp/ChangeLog:
* configure: Regenerate.
libstdc++-v3/ChangeLog:
* configure: Regenerate.
sizeof a VLA type is not a constant in C or the GNU C++ extension, so we
need to capture the VLA even in unevaluated context. For PR60855 we stopped
looking through a previous capture, but we also need to capture the first
time the variable is mentioned.
PR c++/86216
* semantics.c (process_outer_var_ref): Capture VLAs even in
unevaluated context.
The remaining low-hanging fruit for improvement on memory consumption in the
14179 testcase was the duplication of the CONSTRUCTOR for the array by
reshape_init. This patch changes reshape_init to reuse a single constructor
for an array of non-aggregate type such as the one in the testcase.
PR c++/14179
* decl.c (reshape_init_array_1): Reuse a single CONSTRUCTOR with
non-aggregate elements.
(reshape_init_array): Add first_initializer_p parm.
(reshape_init_r): Change first_initializer_p from bool to tree.
(reshape_init): Pass init to it.
PR14179 and the C counterpart PR12245 are about memory consumption of very
large file-scope arrays. Recently, location wrappers increased memory
consumption significantly: in an array of integer constants, each one will
have a location wrapper, which added up to over 500MB in the 14179
testcase. For this kind of testcase tracking these locations isn't worth
the cost, so this patch turns the wrappers off after 256 elements; any array
that size or larger isn't likely to be interested in the location of
individual integer constants.
PR c++/14179
* parser.c (cp_parser_initializer_list): Suppress location wrappers
after 256 elements.
gcc/analyzer/ChangeLog:
PR analyzer/93457
* region-model.cc (make_region_for_type): Use VOID_TYPE_P rather
than checking against void_type_node.
gcc/testsuite/ChangeLog:
PR analyzer/93457
* gcc.dg/analyzer/pr93457.c: New test.
gcc/analyzer/ChangeLog:
PR analyzer/93373
* region-model.cc (ASSERT_COMPAT_TYPES): Convert to...
(assert_compat_types): ...this, and bail when either type is NULL,
or when VOID_TYPE_P (dst_type).
(region_model::get_lvalue): Update for above conversion.
(region_model::get_rvalue): Likewise.
gcc/testsuite/ChangeLog:
PR analyzer/93373
* gcc.dg/analyzer/torture/pr93373.c: New test.
PR analyzer/93379 reports an ICE within
region_model::update_for_return_superedge when writing the
returned svalue_id to the lhs of the call_stmt
The root cause is that this analyzer code assumed that for any call
with a non-NULL gimple_call_lhs, the called fndecl would have non-void
return type, and thus that a non-null svalue_id would be returned from
region_model::pop_frame. This isn't the case e.g. for a call with
conflicting types where the callee returns void but the caller assumes
int.
This patch fixes the ICE by moving the check for null result so that
it also guards setting the lhs.
gcc/analyzer/ChangeLog:
PR analyzer/93379
* region-model.cc (region_model::update_for_return_superedge):
Move check for null result so that it also guards setting the
lhs.
gcc/testsuite/ChangeLog:
PR analyzer/93379
* gcc.dg/analyzer/torture/pr93379-2.c: New test.
* gcc.dg/analyzer/torture/pr93379.c: New test.
PR analyzer/93438 reports an ICE when merging two region_models
in which an older stack frame has a local pointing to a local in
a more recent stack frame.
stack
older frame
int *: "ow" --+
|
newer frame |
int: "pk" <---+
The root cause is that the state-merging code assumes that all frame
regions in the merged model have already been created.
stack_region::can_merge_p iterates through the frames, creating
and populating each merged frame in turn, so when it attempts to
populate the older frame, it attempts to reference the newer frame in
the merged model, which doesn't exist yet.
This patch reworks stack_region::can_merge_p to use a two-pass approach
in which all frames in the merged model are created first, and then
are all populated, fixing the bug.
gcc/analyzer/ChangeLog:
PR analyzer/93438
* region-model.cc (stack_region::can_merge_p): Split into a two
pass approach, creating all stack regions first, then populating
them.
(selftest::test_state_merging): Add test coverage for (a) the case
of self-merging a model in which a local in an older stack frame
points to a local in a more recent stack frame (which previously
would ICE), and (b) the case of self-merging a model in which a
local points to a global (which previously worked OK).
gcc/testsuite/ChangeLog:
PR analyzer/93438
* gcc.dg/analyzer/torture/pr93438.c: New test.
* gcc.dg/analyzer/torture/pr93438-2.c: New test.
The test FAILs on i686-linux with:
FAIL: g++.dg/pr91838.C (test for excess errors)
Excess errors:
/home/jakub/src/gcc/gcc/testsuite/g++.dg/pr91838.C:7:8: warning: MMX vector return without MMX enabled changes the ABI [-Wpsabi]
/home/jakub/src/gcc/gcc/testsuite/g++.dg/pr91838.C:7:3: warning: MMX vector argument without MMX enabled changes the ABI [-Wpsabi]
and on x86_64-linux with -m32 testing with failure to match the
expected pattern in there (or both with e.g. -m32/-mno-mmx/-mno-sse testing).
The test is also in a wrong directory, has non-standard specification that
it requires c++11 or later.
2020-01-31 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/91838
* g++.dg/pr91838.C: Moved to ...
* g++.dg/opt/pr91838.C: ... here. Require c++11 target instead of
dg-skip-if for c++98. Pass -Wno-psabi -w to avoid psabi style
warnings on vector arg passing or return. Add -masm=att on i?86/x86_64.
Only check for pxor %xmm0, %xmm0 on lp64 i?86/x86_64.
This patch adds support for the SVE intrinsics that map to Armv8.6
bfloat16 instructions. This means that svcvtnt is now a base SVE
function for one type suffix combination; the others are still
SVE2-specific.
This relies on a binutils fix:
https://sourceware.org/ml/binutils/2020-01/msg00450.html
so anyone testing older binutils 2.34 or binutils master sources will
need to upgrade to get clean test results. (At the time of writing,
no released version of binutils has this bug.)
2020-01-31 Richard Sandiford <richard.sandiford@arm.com>
gcc/
* config/aarch64/aarch64.h (TARGET_SVE_BF16): New macro.
* config/aarch64/aarch64-sve-builtins-sve2.h (svcvtnt): Move to
aarch64-sve-builtins-base.h.
* config/aarch64/aarch64-sve-builtins-sve2.cc (svcvtnt): Move to
aarch64-sve-builtins-base.cc.
* config/aarch64/aarch64-sve-builtins-base.h (svbfdot, svbfdot_lane)
(svbfmlalb, svbfmlalb_lane, svbfmlalt, svbfmlalt_lane, svbfmmla)
(svcvtnt): Declare.
* config/aarch64/aarch64-sve-builtins-base.cc (svbfdot, svbfdot_lane)
(svbfmlalb, svbfmlalb_lane, svbfmlalt, svbfmlalt_lane, svbfmmla)
(svcvtnt): New functions.
* config/aarch64/aarch64-sve-builtins-base.def (svbfdot, svbfdot_lane)
(svbfmlalb, svbfmlalb_lane, svbfmlalt, svbfmlalt_lane, svbfmmla)
(svcvtnt): New functions.
(svcvt): Add a form that converts f32 to bf16.
* config/aarch64/aarch64-sve-builtins-shapes.h (ternary_bfloat)
(ternary_bfloat_lane, ternary_bfloat_lanex2, ternary_bfloat_opt_n):
Declare.
* config/aarch64/aarch64-sve-builtins-shapes.cc (parse_element_type):
Treat B as bfloat16_t.
(ternary_bfloat_lane_base): New class.
(ternary_bfloat_def): Likewise.
(ternary_bfloat): New shape.
(ternary_bfloat_lane_def): New class.
(ternary_bfloat_lane): New shape.
(ternary_bfloat_lanex2_def): New class.
(ternary_bfloat_lanex2): New shape.
(ternary_bfloat_opt_n_def): New class.
(ternary_bfloat_opt_n): New shape.
* config/aarch64/aarch64-sve-builtins.cc (TYPES_cvt_bfloat): New macro.
* config/aarch64/aarch64-sve.md (@aarch64_sve_<sve_fp_op>vnx4sf)
(@aarch64_sve_<sve_fp_op>_lanevnx4sf): New patterns.
(@aarch64_sve_<optab>_trunc<VNx4SF_ONLY:mode><VNx8BF_ONLY:mode>)
(@cond_<optab>_trunc<VNx4SF_ONLY:mode><VNx8BF_ONLY:mode>): Likewise.
(*cond_<optab>_trunc<VNx4SF_ONLY:mode><VNx8BF_ONLY:mode>): Likewise.
(@aarch64_sve_cvtnt<VNx8BF_ONLY:mode>): Likewise.
* config/aarch64/aarch64-sve2.md (@aarch64_sve2_cvtnt<mode>): Key
the pattern off the narrow mode instead of the wider one.
* config/aarch64/iterators.md (VNx8BF_ONLY): New mode iterator.
(UNSPEC_BFMLALB, UNSPEC_BFMLALT, UNSPEC_BFMMLA): New unspecs.
(sve_fp_op): Handle them.
(SVE_BFLOAT_TERNARY_LONG): New int itertor.
(SVE_BFLOAT_TERNARY_LONG_LANE): Likewise.
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_aarch64_asm_bf16_ok):
New proc.
* gcc.target/aarch64/sve/acle/asm/bfdot_f32.c: New test.
* gcc.target/aarch64/sve/acle/asm/bfdot_lane_f32.c: Likweise.
* gcc.target/aarch64/sve/acle/asm/bfmlalb_f32.c: Likweise.
* gcc.target/aarch64/sve/acle/asm/bfmlalb_lane_f32.c: Likweise.
* gcc.target/aarch64/sve/acle/asm/bfmlalt_f32.c: Likweise.
* gcc.target/aarch64/sve/acle/asm/bfmlalt_lane_f32.c: Likweise.
* gcc.target/aarch64/sve/acle/asm/bfmmla_f32.c: Likweise.
* gcc.target/aarch64/sve/acle/asm/cvt_bf16.c: Likweise.
* gcc.target/aarch64/sve/acle/asm/cvtnt_bf16.c: Likweise.
* gcc.target/aarch64/sve/acle/general-c/ternary_bfloat16_1.c: Likweise.
* gcc.target/aarch64/sve/acle/general-c/ternary_bfloat16_lane_1.c:
Likweise.
* gcc.target/aarch64/sve/acle/general-c/ternary_bfloat16_lanex2_1.c:
Likweise.
* gcc.target/aarch64/sve/acle/general-c/ternary_bfloat16_opt_n_1.c:
Likweise.
It seems that in practice std::sentinel_for<I, I> is always true, and so the
test_range container doesn't help us detect bugs in ranges code in which we
wrongly assume that a sentinel can be manipulated like an iterator. Make the
test_range range more strict by having end() unconditionally return a
sentinel<I>, and adjust some tests accordingly.
libstdc++-v3/ChangeLog:
* testsuite/24_iterators/range_operations/distance.cc: Do not assume
test_range::end() returns the same type as test_range::begin().
* testsuite/24_iterators/range_operations/next.cc: Likewise.
* testsuite/24_iterators/range_operations/prev.cc: Likewise.
* testsuite/util/testsuite_iterators.h (__gnu_test::test_range::end):
Always return a sentinel<I>.
Fix ICE in testcase gfortran.dg/assumed_rank_bounds_3.f90.
2020-01-31 Andrew Stubbs <ams@codesourcery.com>
gcc/
* config/gcn/gcn-valu.md (addv64di3_exec): Allow one '0' in each
alternative only.
The reason for TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL on AMD target is
only insn size, as advised in e.g. Software Optimization Guide for the
AMD Family 15h Processors [1], section 7.1.2, where it is said:
--quote--
7.1.2 Reduce Instruction SizeOptimization
Reduce the size of instructions when possible.
Rationale
Using smaller instruction sizes improves instruction fetch throughput.
Specific examples include the following:
*In SIMD code, use the single-precision (PS) form of instructions
instead of the double-precision (PD) form. For example, for register
to register moves, MOVAPS achieves the same result as MOVAPD, but uses
one less byte to encode the instruction and has no prefix byte. Other
examples in which single-precision forms can be substituted for
double-precision forms include MOVUPS, MOVNTPS, XORPS, ORPS, ANDPS,
and SHUFPS.
...
--/quote--
Please note that this optimization applies only to non-AVX forms, as
demonstrated by:
0: 0f 28 c8 movaps %xmm0,%xmm1
3: 66 0f 28 c8 movapd %xmm0,%xmm1
7: c5 f8 28 d1 vmovaps %xmm1,%xmm2
b: c5 f9 28 d1 vmovapd %xmm1,%xmm2
Also note that MOVDQA is missing in the above optimization. It is
harmful to substitute MOVDQA with MOVAPS, as it can (and does)
introduce +1 cycle forwarding penalty between FLT (FPA/FPM) and INT
(VALU) FP clusters.
[1] https://www.amd.com/system/files/TechDocs/47414_15h_sw_opt_guide.pdf
2020-01-31 Kwok Cheung Yeung <kcy@codesourcery.com>
gcc/
* config/gcn/mkoffload.c (process_asm): Add sgpr_count and vgpr_count
to definition of hsa_kernel_description. Parse assembly to find SGPR
and VGPR count of kernel and store in hsa_kernel_description.
libgomp/
* plugin/plugin-gcn.c (struct hsa_kernel_description): Add sgpr_count
and vgpr_count fields.
(struct kernel_info): Add a field for a hsa_kernel_description.
(run_kernel): Reduce the number of threads/workers if the requested
number would require too many VGPRs.
(init_basic_kernel_info): Initialize description field with
the hsa_kernel_description entry for the kernel.
This fixes a fall-out from a patch I had submitted two years ago which started
allowing simplify-rtx to fold logical right shifts by offsets a followed by b
into >> (a + b).
However this can generate inefficient code when the resulting shift count ends
up being the same as the size of the shift mode. This will create some
undefined behavior on most platforms.
This patch changes to code to truncate to 0 if the shift amount goes out of
range. Before my older patch this used to happen in combine when it saw the
two shifts. However since we combine them here combine never gets a chance to
truncate them.
The issue mostly affects GCC 8 and 9 since on 10 the back-end knows how to deal
with this shift constant but it's better to do the right thing in simplify-rtx.
Note that this doesn't take care of the Arithmetic shift where you could replace
the constant with MODE_BITS (mode) - 1, but that's not a regression so punting it.
gcc/ChangeLog:
PR rtl-optimization/91838
* simplify-rtx.c (simplify_binary_operation_1): Update LSHIFTRT case
to truncate if allowed or reject combination.
gcc/testsuite/ChangeLog:
PR rtl-optimization/91838
* g++.dg/pr91838.C: New test.
This patch refactors some code in special_function_p that checks for
the function being sane to match by name, splitting it out into a new
maybe_special_function_p, and using it it two places in the analyzer.
gcc/analyzer/ChangeLog:
* analyzer.cc (is_named_call_p): Replace tests for fndecl being
extern at file scope and having a non-NULL DECL_NAME with a call
to maybe_special_function_p.
* function-set.cc (function_set::contains_decl_p): Add call to
maybe_special_function_p.
gcc/ChangeLog:
* calls.c (special_function_p): Split out the check for DECL_NAME
being non-NULL and fndecl being extern at file scope into a
new maybe_special_function_p and call it. Drop check for fndecl
being non-NULL that was after a usage of DECL_NAME (fndecl).
* tree.h (maybe_special_function_p): New inline function.
gcc/analyzer/ChangeLog:
PR analyzer/93450
* constraint-manager.cc
(constraint_manager::get_or_add_equiv_class): Only compare constants
if their types are compatible.
* region-model.cc (constant_svalue::eval_condition): Replace check
for identical types with call to types_compatible_p.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (for_each_state_change): Use
extrinsic_state::get_num_checkers rather than accessing m_checkers
directly.
* program-state.cc (program_state::program_state): Likewise.
* program-state.h (extrinsic_state::m_checkers): Make private.
This test assumes that memset and strlen have been marked with
__attribute__((nonnull)), which isn't necessarily the case for an
arbitrary <string.h>. This likely explains these failures:
FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 417)
FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 418)
FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 425)
FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 429)
seen in https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01608.html
on x86_64-apple-darwin18.
Fix it by using the __builtin_ forms.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/malloc-1.c: Remove include of <string.h>.
Use __builtin_ forms of memset and strlen throughout.
PR analyzer/93356 reports an ICE handling __builtin_isnan due to a
failing assertion:
674 gcc_assert (lhs_ec_id != rhs_ec_id);
with op=UNORDERED_EXPR.
when attempting to add an UNORDERED_EXPR constraint.
This is an overzealous assertion, but underlying it are various forms of
sloppiness regarding NaN within the analyzer:
(a) the assumption in the constraint_manager that equivalence classes
are reflexive (X == X), which isn't the case for NaN.
(b) Hardcoding the "honor_nans" param to false when calling
invert_tree_comparison throughout the analyzer.
(c) Ignoring ORDERED_EXPR, UNORDERED_EXPR, and the UN-prefixed
comparison codes.
I wrote a patch for this which tracks the NaN-ness of floating-point
values and uses this to address all of the above.
However, to minimize changes in gcc 10 stage 4, here's a simpler patch
which rejects attempts to query or add constraints on floating-point
values, instead treating any floating-point comparison as "unknown", and
silently dropping the constraints at edges.
gcc/analyzer/ChangeLog:
PR analyzer/93356
* region-model.cc (region_model::eval_condition): In both
overloads, bail out immediately on floating-point types.
(region_model::eval_condition_without_cm): Likewise.
(region_model::add_constraint): Likewise.
gcc/testsuite/ChangeLog:
PR analyzer/93356
* gcc.dg/analyzer/conditionals-notrans.c (test_float_selfcmp):
Add.
* gcc.dg/analyzer/conditionals-trans.c: Mark floating point
comparison test as failing.
(test_float_selfcmp): Add.
* gcc.dg/analyzer/data-model-1.c: Mark floating point comparison
tests as failing.
* gcc.dg/analyzer/torture/pr93356.c: New test.
gcc/ChangeLog:
PR analyzer/93356
* doc/analyzer.texi (Limitations): Note that constraints on
floating-point values are currently ignored.
The following testcase FAILs on powerpc64le-linux with assembler errors, as we
emit a call to bar.localalias, then .set bar.localalias, bar twice and then
another call to bar.localalias. The problem is that bar.localalias can be created
at various stages and e.g. ipa-pure-const can slightly adjust the original decl,
so that the existing bar.localalias isn't considered usable (different
flags_from_decl_or_type). In that case, we'd create another bar.localalias, which
clashes with the existing name.
Fixed by retrying with another name if it is already present. The various localalias
aliases shouldn't be that many, from different partitions they would be lto_priv
suffixed and in most cases they would already have the same type/flags/attributes.
2020-01-30 Jakub Jelinek <jakub@redhat.com>
PR lto/93384
* symtab.c (symtab_node::noninterposable_alias): If localalias
already exists, but is not usable, append numbers after it until
a unique name is found. Formatting fix.
* gcc.dg/lto/pr93384_0.c: New test.
* gcc.dg/lto/pr93384_1.c: New file.
What happens on this testcase is with the out of bounds rotate we get:
Trying 13 -> 16:
13: r129:SI=r132:DI#0<-<0x20
REG_DEAD r132:DI
16: r123:DI=r129:SI<0
REG_DEAD r129:SI
Successfully matched this instruction:
(set (reg/v:DI 123 [ <retval> ])
(const_int 0 [0]))
during combine. So, perhaps we could also change simplify-rtx.c to punt
if it is out of bounds rather than trying to optimize anything.
Or, but probably GCC11 material, if we decide that ROTATE/ROTATERT doesn't
have out of bounds counts or introduce targetm.rotate_truncation_mask,
we should truncate the argument instead of punting.
Punting is better for backports though.
2020-01-30 Jakub Jelinek <jakub@redhat.com>
PR middle-end/93505
* combine.c (simplify_comparison) <case ROTATE>: Punt on out of range
rotate counts.
* gcc.c-torture/compile/pr93505.c: New test.
When instantiating a template tsubst_copy_and_build suppresses -Wtype-limits
warnings about e.g. == always being false because it might not always be
false for an instantiation with other template arguments. But we should
warn if the operands don't depend on template arguments.
PR c++/82521
* pt.c (tsubst_copy_and_build) [EQ_EXPR]: Only suppress warnings if
the expression was dependent before substitution.
PR fortran/87103
* expr.c (gfc_check_conformance): Check vsnprintf for truncation.
* iresolve.c (gfc_get_string): Likewise.
* symbol.c (gfc_new_symbol): Remove check for maximum symbol
name length. Remove redundant 0 setting of new calloc()ed
gfc_symbol.
This wraps { ... } in _Literal (type) for consumption by the GIMPLE FE.
2020-01-30 Richard Biener <rguenther@suse.de>
* tree-pretty-print.c (dump_generic_node): Wrap VECTOR_CST
and CONSTRUCTOR in _Literal (type) with TDF_GIMPLE.
PR analyzer/93450 reports an ICE trying to fold an EQ_EXPR comparison
of (int)0 with (float)Inf.
Most comparisons inside the analyzer come from gimple conditions, for
which the necessary casts have already been added.
This one is done inside constant_svalue::eval_condition as part of
purging sm-state for an unknown function call, and fails to check
the types being compared, leading to the ICE.
sm_state_map::set_state calls region_model::eval_condition_without_cm in
order to handle pointer equality (so that e.g. (void *)&r and (foo *)&r
transition together), which leads to this code generating a bogus query
to see if the two constants are equal.
This patch fixes the ICE in two ways:
- It avoids generating comparisons within
constant_svalue::eval_condition unless the types are equal (thus for
constants, but not for pointer values, which are handled by
region_svalue).
- It updates sm_state_map::set_state to bail immediately if the new
state is the same as the old one, thus avoiding the above for the
common case where an svalue_id has no sm-state (such as for the int
and float constants in the reproducer), for which the above becomes a
no-op.
gcc/analyzer/ChangeLog:
PR analyzer/93450
* program-state.cc (sm_state_map::set_state): For the overload
taking an svalue_id, bail out if the set_state on the ec does
nothing. Convert the latter's return type from void to bool,
returning true if anything changed.
(sm_state_map::impl_set_state): Convert the return type from void
to bool, returning true if the state changed.
* program-state.h (sm_state_map::set_state): Convert return type
from void to bool.
(sm_state_map::impl_set_state): Likewise.
* region-model.cc (constant_svalue::eval_condition): Only call
fold_build2 if the types are the same.
gcc/testsuite/ChangeLog:
PR analyzer/93450
* gcc.dg/analyzer/torture/pr93450.c: New test.
