| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This makes sure to not generate a shift of pointer types in
simplification of X < (cast) (1 << Y).
2021-08-11 Richard Biener <rguenther@suse.de>
PR middle-end/101858
* fold-const.c (fold_binary_loc): Guard simplification
of X < (cast) (1 << Y) to integer types.
* gcc.dg/pr101858.c: New testcase.
|
|
Resolves:
PR c/101289 - bogus -Wvla-paramater warning when using const for vla param
PR c/97548 - bogus -Wvla-parameter on a bound expression involving a parameter
gcc/c-family/ChangeLog:
PR c/101289
PR c/97548
* c-warn.c (warn_parm_array_mismatch): Use OEP_DECL_NAME.
gcc/c/ChangeLog:
PR c/101289
PR c/97548
* c-decl.c (get_parm_array_spec): Strip nops.
gcc/ChangeLog:
PR c/101289
PR c/97548
* fold-const.c (operand_compare::operand_equal_p): Handle OEP_DECL_NAME.
(operand_compare::verify_hash_value): Same.
* tree-core.h (OEP_DECL_NAME): New.
gcc/testsuite/ChangeLog:
* gcc.dg/Wvla-parameter-12.c: New test.
|
|
HONOR_SIGNED_ZEROS, HONOR_SIGN_DEPENDENT_ROUNDING, and HONOR_SNANS all
have an overload for taking a tree type now, so we should do that instead.
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
PR middle-end/101237
* fold-const.c (negate_expr_p): Remove call to element_mode
and TREE_MODE/TREE_TYPE when calling HONOR_SIGNED_ZEROS,
HONOR_SIGN_DEPENDENT_ROUNDING, and HONOR_SNANS.
(fold_negate_expr_1): Likewise.
(const_unop): Likewise.
(fold_cond_expr_with_comparison): Likewise.
(fold_binary_loc): Likewise.
(fold_ternary_loc): Likewise.
(tree_call_nonnegative_warnv_p): Likewise.
* match.pd (-(A + B) -> (-B) - A): Likewise.
|
|
This fixes PR 101230 where I had messed up and forgot that
invert_tree_comparison can return ERROR_MARK if the comparsion
is not invertable (floating point types).
Committed as obvious after a bootstrap/test on x86_64-linux-gnu-gnu
gcc/ChangeLog:
PR middle-end/101230
* fold-const.c (fold_ternary_loc): Check
the return value of invert_tree_comparison.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr101230-1.c: New test.
|
|
To make things slightly easiler to convert fold_cond_expr_with_comparison
over to match.pd, expanding the arg0 argument into 3 different arguments
is done. Also this was simple because we don't use arg0 after grabbing
the code and the two operands.
Also since we do this, we don't need to fold the comparison to
get the inverse but just use invert_tree_comparison directly.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* fold-const.c (fold_cond_expr_with_comparison):
Exand arg0 into comp_code, arg00, and arg01.
(fold_ternary_loc): Use invert_tree_comparison
instead of fold_invert_truthvalue for the case
where we have A CMP B ? C : A.
|
|
gcc/ChangeLog:
* builtins.c (warn_string_no_nul): Replace uses of TREE_NO_WARNING,
gimple_no_warning_p and gimple_set_no_warning with
warning_suppressed_p, and suppress_warning.
(c_strlen): Same.
(maybe_warn_for_bound): Same.
(warn_for_access): Same.
(check_access): Same.
(expand_builtin_strncmp): Same.
(fold_builtin_varargs): Same.
* calls.c (maybe_warn_nonstring_arg): Same.
(maybe_warn_rdwr_sizes): Same.
* cfgexpand.c (expand_call_stmt): Same.
* cgraphunit.c (check_global_declaration): Same.
* fold-const.c (fold_undefer_overflow_warnings): Same.
(fold_truth_not_expr): Same.
(fold_unary_loc): Same.
(fold_checksum_tree): Same.
* gimple-array-bounds.cc (array_bounds_checker::check_array_ref): Same.
(array_bounds_checker::check_mem_ref): Same.
(array_bounds_checker::check_addr_expr): Same.
(array_bounds_checker::check_array_bounds): Same.
* gimple-expr.c (copy_var_decl): Same.
* gimple-fold.c (gimple_fold_builtin_strcpy): Same.
(gimple_fold_builtin_strncat): Same.
(gimple_fold_builtin_stxcpy_chk): Same.
(gimple_fold_builtin_stpcpy): Same.
(gimple_fold_builtin_sprintf): Same.
(fold_stmt_1): Same.
* gimple-ssa-isolate-paths.c (diag_returned_locals): Same.
* gimple-ssa-nonnull-compare.c (do_warn_nonnull_compare): Same.
* gimple-ssa-sprintf.c (handle_printf_call): Same.
* gimple-ssa-store-merging.c (imm_store_chain_info::output_merged_store): Same.
* gimple-ssa-warn-restrict.c (maybe_diag_overlap): Same.
* gimple-ssa-warn-restrict.h: Adjust declarations.
(maybe_diag_access_bounds): Replace uses of TREE_NO_WARNING,
gimple_no_warning_p and gimple_set_no_warning with
warning_suppressed_p, and suppress_warning.
(check_call): Same.
(check_bounds_or_overlap): Same.
* gimple.c (gimple_build_call_from_tree): Same.
* gimplify.c (gimplify_return_expr): Same.
(gimplify_cond_expr): Same.
(gimplify_modify_expr_complex_part): Same.
(gimplify_modify_expr): Same.
(gimple_push_cleanup): Same.
(gimplify_expr): Same.
* omp-expand.c (expand_omp_for_generic): Same.
(expand_omp_taskloop_for_outer): Same.
* omp-low.c (lower_rec_input_clauses): Same.
(lower_lastprivate_clauses): Same.
(lower_send_clauses): Same.
(lower_omp_target): Same.
* tree-cfg.c (pass_warn_function_return::execute): Same.
* tree-complex.c (create_one_component_var): Same.
* tree-inline.c (remap_gimple_op_r): Same.
(copy_tree_body_r): Same.
(declare_return_variable): Same.
(expand_call_inline): Same.
* tree-nested.c (lookup_field_for_decl): Same.
* tree-sra.c (create_access_replacement): Same.
(generate_subtree_copies): Same.
* tree-ssa-ccp.c (pass_post_ipa_warn::execute): Same.
* tree-ssa-forwprop.c (combine_cond_expr_cond): Same.
* tree-ssa-loop-ch.c (ch_base::copy_headers): Same.
* tree-ssa-loop-im.c (execute_sm): Same.
* tree-ssa-phiopt.c (cond_store_replacement): Same.
* tree-ssa-strlen.c (maybe_warn_overflow): Same.
(handle_builtin_strcpy): Same.
(maybe_diag_stxncpy_trunc): Same.
(handle_builtin_stxncpy_strncat): Same.
(handle_builtin_strcat): Same.
* tree-ssa-uninit.c (get_no_uninit_warning): Same.
(set_no_uninit_warning): Same.
(uninit_undefined_value_p): Same.
(warn_uninit): Same.
(maybe_warn_operand): Same.
* tree-vrp.c (compare_values_warnv): Same.
* vr-values.c (vr_values::extract_range_for_var_from_comparison_expr): Same.
(test_for_singularity): Same.
* gimple.h (warning_suppressed_p): New function.
(suppress_warning): Same.
(copy_no_warning): Same.
(gimple_set_block): Call gimple_set_location.
(gimple_set_location): Call copy_warning.
|
|
range_check_type [PR101162]
Andrew's recent r12-1608-g2f1686ff70b25fceb04ca2ffc0a450fb682913ef change
to fail verification on various unary and binary operations with OFFSET_TYPE
revealed that e.g. switchconv happily performs multiplications and additions
in OFFSET_TYPE.
2021-06-22 Jakub Jelinek <jakub@redhat.com>
Andrew Pinski <apinski@marvell.com>
PR tree-optimization/101162
* fold-const.c (range_check_type): Handle OFFSET_TYPE like pointer
types.
* g++.dg/opt/pr101162.C: New test.
|
|
The patch implements a missed optimization enhancement. Under usual
IEEE rules, x+0.0 can't be simplified to x when x might potentially
be an IEEE minus zero (-0.0). The current logic in the middle-end
checks whether the type of x should honor signed zeros, but with this
patch we introduce tree_expr_maybe_real_minus_zero_p that allows us
to confirm that the value can't possibly be -0.0, for example, the result
of a conversion from an integer type, or the result of fabs (or has a
type that doesn't honor signed zero).
Whilst modifying match.pd, I also converted some additional folding
transformations from "testing the type" to "testing the value".
2020-06-10 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR tree-optimization/96392
* fold-const.c (fold_real_zero_addition_p): Take both arguments
of the addition or subtraction, not just the zero. Use this
other argument in tests for signaling NaNs and signed zeros.
(tree_expr_maybe_real_minus_zero_p): New predicate.
* fold-const.h (fold_real_zero_addition_p): Update prototype.
(tree_expr_maybe_real_minus_zero_p): New function prototype.
* match.pd: Update calls to fold_real_zero_addition_p.
Replace HONOR_NANS with tree_expr_maybe_nan_p.
Replace HONOR_SIGNED_ZEROS with tree_expr_maybe_real_minus_zero_p.
Replace HONOR_SNANS with tree_expr_maybe_signaling_nan_p.
* tree-ssa-reassoc.c (eliminate_using_constants): Update
call to fold_real_zero_addition_p.
gcc/testsuite/ChangeLog
PR tree-optimization/96392
* gcc.dg/pr96392.c: New test.
|
|
The callers of fold_read_from_vector expect that the index they pass is
an index of an element in the vector and the function does that most of the
time. But we allow CONSTRUCTORs with VECTOR_TYPE to have VECTOR_TYPE
elements and in that case every CONSTRUCTOR element represents not just one
index (with the exception of V1 vectors), but multiple.
So returning zero vector if i >= CONSTRUCTOR_NELTS or returning some
CONSTRUCTOR_ELT's value might not be what the callers expect.
Fixed by punting if the first element has vector type.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
In theory we could instead recurse (and assert that for CONSTRUCTORs of
vector elements we have always all elements specified like tree-cfg.c
verifies?) after adjusting the index appropriately.
2021-06-07 Jakub Jelinek <jakub@redhat.com>
PR target/100887
* fold-const.c (fold_read_from_vector): Return NULL if trying to
read from a CONSTRUCTOR with vector type elements.
* gcc.dg/pr100887.c: New test.
|
|
This patch converts the remaining users of get_range_info and
get_ptr_nonnull to the get_range_query API.
No effort was made to move passes away from VR_ANTI_RANGE, or any other
use of deprecated methods. This was a straight up conversion to the new
API, nothing else.
gcc/ChangeLog:
* builtins.c (check_nul_terminated_array): Convert to get_range_query.
(expand_builtin_strnlen): Same.
(determine_block_size): Same.
* fold-const.c (expr_not_equal_to): Same.
* gimple-fold.c (size_must_be_zero_p): Same.
* gimple-match-head.c: Include gimple-range.h.
* gimple-pretty-print.c (dump_ssaname_info): Convert to get_range_query.
* gimple-ssa-warn-restrict.c
(builtin_memref::extend_offset_range): Same.
* graphite-sese-to-poly.c (add_param_constraints): Same.
* internal-fn.c (get_min_precision): Same.
* ipa-fnsummary.c (set_switch_stmt_execution_predicate): Same.
* ipa-prop.c (ipa_compute_jump_functions_for_edge): Same.
* match.pd: Same.
* tree-data-ref.c (split_constant_offset): Same.
(dr_step_indicator): Same.
* tree-dfa.c (get_ref_base_and_extent): Same.
* tree-scalar-evolution.c (iv_can_overflow_p): Same.
* tree-ssa-loop-niter.c (refine_value_range_using_guard): Same.
(determine_value_range): Same.
(record_nonwrapping_iv): Same.
(infer_loop_bounds_from_signedness): Same.
(scev_var_range_cant_overflow): Same.
* tree-ssa-phiopt.c (two_value_replacement): Same.
* tree-ssa-pre.c (insert_into_preds_of_block): Same.
* tree-ssa-reassoc.c (optimize_range_tests_to_bit_test): Same.
* tree-ssa-strlen.c (handle_builtin_stxncpy_strncat): Same.
(get_range): Same.
(dump_strlen_info): Same.
(set_strlen_range): Same.
(maybe_diag_stxncpy_trunc): Same.
(get_len_or_size): Same.
(handle_integral_assign): Same.
* tree-ssa-structalias.c (find_what_p_points_to): Same.
* tree-ssa-uninit.c (find_var_cmp_const): Same.
* tree-switch-conversion.c (bit_test_cluster::emit): Same.
* tree-vect-patterns.c (vect_get_range_info): Same.
(vect_recog_divmod_pattern): Same.
* tree-vrp.c (intersect_range_with_nonzero_bits): Same.
(register_edge_assert_for_2): Same.
(determine_value_range_1): Same.
* tree.c (get_range_pos_neg): Same.
* vr-values.c (vr_values::get_lattice_entry): Same.
(vr_values::update_value_range): Same.
(simplify_conversion_using_ranges): Same.
|
|
gcc/ChangeLog:
* asan.h (sanitize_coverage_p): New function.
* doc/extend.texi: Document it.
* fold-const.c (fold_range_test): Use sanitize_flags_p
instead of flag_sanitize_coverage.
(fold_truth_andor): Likewise.
* sancov.c: Likewise.
* tree-ssa-ifcombine.c (ifcombine_ifandif): Likewise.
* ipa-inline.c (sanitize_attrs_match_for_inline_p): Handle
-fsanitize-coverage when inlining.
gcc/c-family/ChangeLog:
* c-attribs.c (handle_no_sanitize_coverage_attribute): New.
gcc/testsuite/ChangeLog:
* gcc.dg/sancov/attribute.c: New test.
|
|
This fixes the bogus use of TYPE_PRECISION on vector types
from optimizing -((int)x >> 31) into (unsigned)x >> 31.
2021-05-19 Richard Biener <rguenther@suse.de>
PR middle-end/100672
* fold-const.c (fold_negate_expr_1): Use element_precision.
(negate_expr_p): Likewise.
* gcc.dg/torture/pr100672.c: New testcase.
|
|
This removes pedantic_non_lvalue_loc which doesn't do what it says
since quite some time in favor of what it actually does and where
that's not a duplicate (protected_set_expr_location_unshare).
2021-04-19 Richard Biener <rguenther@suse.de>
* fold-const.c (pedantic_non_lvalue_loc): Remove.
(fold_binary_loc): Adjust.
(fold_ternary_loc): Likewise.
|
|
print_rtl will dump the rtx_insn from current until LAST. But it is only
useful to see the particular insn that called by print_rtx_insn_vec,
Let's call print_rtl_single to display that insn in the gcse and store-motion
pass dump.
2021-04-07 Xionghu Luo <luoxhu@linux.ibm.com>
gcc/ChangeLog:
* fold-const.c (fold_single_bit_test): Fix typo.
* print-rtl.c (print_rtx_insn_vec): Call print_rtl_single
instead.
|
|
extract_muldiv{,_1} is apparently only prepared to handle scalar integer
operations, the callers ensure it by only calling it if the divisor or
one of the multiplicands is INTEGER_CST and because neither multiplication
nor division nor modulo are really supported e.g. for pointer types, nullptr
type etc. But the CASE_CONVERT handling doesn't really check if it isn't
a cast from some other type kind, so on the testcase we end up trying to
build MULT_EXPR in POINTER_TYPE which ICEs. A few years ago Marek has
added ANY_INTEGRAL_TYPE_P checks to two spots, but the code uses
TYPE_PRECISION which means something completely different for vector types,
etc.
So IMNSHO we should just punt on conversions from non-integrals or
non-scalar integrals.
2021-03-29 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/99777
* fold-const.c (extract_muldiv_1): For conversions, punt on casts from
types other than scalar integral types.
* g++.dg/torture/pr99777.C: New test.
|
|
Honza has fairly recently changed operand_equal_p to compare
DECL_FIELD_OFFSET for COMPONENT_REFs when comparing addresses.
As the first testcase in this patch shows, while that is very nice
for optimizations, for the -Wduplicated-branches warning it causes
regressions. Pedantically a union in both C and C++ has only one
active member at a time, so using some other union member even if it has the
same type is UB, so I think the warning shouldn't warn when it sees access
to different fields that happen to have the same offset and should consider
them different.
In my first attempt to fix this I've keyed the old behavior on
OEP_LEXICOGRAPHIC, but unfortunately that has various problems, the warning
has a quick non-lexicographic compare in build_conditional_expr* and another
lexicographic more expensive one later during genericization and turning the
first one into lexicographic would mean wasting compile time on large
conditionals.
So, this patch instead introduces a new OEP_ flag and makes sure to pass it
to operand_equal_p in all -Wduplicated-branches cases.
The cvt.c changes are because on the other testcase we were warning with
UNKNOWN_LOCATION, so the user wouldn't really know where the questionable
code is.
2021-03-25 Jakub Jelinek <jakub@redhat.com>
PR c++/99565
* tree-core.h (enum operand_equal_flag): Add OEP_ADDRESS_OF_SAME_FIELD.
* fold-const.c (operand_compare::operand_equal_p): Don't compare
field offsets if OEP_ADDRESS_OF_SAME_FIELD.
* c-warn.c (do_warn_duplicated_branches): Pass also
OEP_ADDRESS_OF_SAME_FIELD to operand_equal_p.
* c-typeck.c (build_conditional_expr): Pass OEP_ADDRESS_OF_SAME_FIELD
to operand_equal_p.
* call.c (build_conditional_expr_1): Pass OEP_ADDRESS_OF_SAME_FIELD
to operand_equal_p.
* cvt.c (convert_to_void): Preserve location_t on COND_EXPR or
or COMPOUND_EXPR.
* g++.dg/warn/Wduplicated-branches6.C: New test.
* g++.dg/warn/Wduplicated-branches7.C: New test.
|
|
The segfault occurs in native_encode_initializer when it is encoding the
CONSTRUCTOR for an array whose lower bound is negative (it's OK in Ada).
The computation of the current position is done in HOST_WIDE_INT and this
does not work for arrays whose original range has a negative lower bound
and a positive upper bound; the computation must be done in sizetype
instead so that it may wrap around.
gcc/
PR middle-end/99641
* fold-const.c (native_encode_initializer) <CONSTRUCTOR>: For an
array type, do the computation of the current position in sizetype.
|
|
This optimization was written purely with scalar integers in mind,
can work fine even with vectors, but we can't use build_int_cst but
need to use build_one_cst instead.
2021-02-24 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/99225
* fold-const.c (fold_binary_loc) <case NE_EXPR>: In (x & (1 << y)) != 0
to ((x >> y) & 1) != 0 simplifications use build_one_cst instead of
build_int_cst (..., 1). Formatting fixes.
* gcc.c-torture/compile/pr99225.c: New test.
|
|
fold_read_from_constant_string and expand_expr_real_1 have code to optimize
constant reads from string (tree vs. rtl).
If the STRING_CST array type has zero low bound, index is fold converted to
sizetype and so the compare_tree_int works fine, but if it has some other
low bound, it calls size_diffop_loc and that function from 2 sizetype
operands creates a ssizetype difference. expand_expr_real_1 then uses
tree_fits_uhwi_p + compare_tree_int and so works fine, but fold-const.c
only checked if index is INTEGER_CST and calls compare_tree_int, which means
for negative index it will succeed and result in UB in the compiler.
2021-02-23 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/99204
* fold-const.c (fold_read_from_constant_string): Check that
tree_fits_uhwi_p (index) rather than just that index is INTEGER_CST.
* gfortran.dg/pr99204.f90: New test.
|
|
|
|
[PR98206]
The following testcase is diagnosed by UBSan as invalid, even when it is
valid.
We have a derived type Base2 at offset 1 with alignment 1 and do:
(const Derived &) ((const Base2 *) this + -1)
but the folder before ubsan in the FE gets a chance to instrument it
optimizes that into:
(const Derived &) this + -1
and so we require that this has 8-byte alignment which Derived class needs.
Fixed by avoiding such an optimization when -fsanitize=alignment is in
effect if it would affect the alignments (and guarded with !in_gimple_form
because we don't really care during GIMPLE, though pointer conversions are
useless then and so such folding isn't needed very much during GIMPLE).
2020-12-31 Jakub Jelinek <jakub@redhat.com>
PR c++/98206
* fold-const.c: Include asan.h.
(fold_unary_loc): Don't optimize (ptr_type) (((ptr_type2) x) p+ y)
into ((ptr_type) x) p+ y if sanitizing alignment in GENERIC and
ptr_type points to type with higher alignment than ptr_type2.
* g++.dg/ubsan/align-4.C: New test.
|
|
For flexible array members we need to incrementally clear just from
ptr + total_bytes up to new ptr + total_bytes, but memset has been called
with the length from ptr, so was missing - total_bytes. Additionally,
in this code off is guaranteed to be -1 and thus o 0, so don't bother pretending
we could handle anything else, it would be more complicated than that.
2020-12-21 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/98407
* fold-const.c (native_encode_initializer): When handling flexible
array members, fix up computation of length for memset. Also remove
" - o" as o is always guaranteed to be 0 in this code path.
* gcc.c-torture/compile/pr98407.c: New test.
|
|
constant_byte_string now uses a convert_to_bytes function, which doesn't
handle bitfields at all (don't punt on them, just puts them into wrong bits
or bytes). Furthermore, I don't see a reason why that function should exist
at all, it duplicates native_encode_initializer functionality.
Except that native_encode_initializer punted on flexible array members and 2
tests in the testsuite relied on constant_byte_string handling those.
So, this patch throws away convert_to_bytes, uses native_encode_initializer
instead, but teaches it to handle flexible array members (only in the
non-mask mode with off == -1 for now), furthermore, it adds various corner
case checks that the old implementation was missing (like that STRING_CSTs
use int as length and therefore we shouldn't try to build larger than that
strings, or that native_encode*/native_interpret* APIs require sane
host and target bytes (8-bit on both).
2020-12-19 Jakub Jelinek <jakub@redhat.com>
PR middle-end/98366
* fold-const.c (native_encode_initializer): Don't try to
memset more than total_bytes with off == -1 even if len is large.
Handle flexible array member initializers if off == -1 and mask is
NULL.
* expr.c (convert_to_bytes): Remove.
(constant_byte_string): Use native_encode_initializer instead of
convert_to_bytes. Remove extraneous semicolon. Punt on various
corner-cases the APIs don't handle, like sizes > INT_MAX,
BITS_PER_UNIT != 8, CHAR_BIT != 8.
* gcc.c-torture/execute/pr98366.c: New test.
|
|
With the bit_cast changes, I have added support for bitfields which don't
have scalar representatives. For bit_cast it works fine, as when mask
is non-NULL, off is asserted to be 0. But when native_encode_initializer
is called e.g. from sccvn with off > 0 (i.e. we are interested in encoding
just a few bytes out of it somewhere from the middle or at the end), the
following computations are incorrect.
pos is a byte position from the start of the constructor, repr_size is the
size in bytes of the bit-field representative and len is the length
of the buffer. If the buffer is offsetted by positive off, those numbers
are uncomparable though, we need to add off to len to make both
count bytes from the start of the constructor, and o is a utility temporary
set to off != -1 ? off : 0 (because off -1 also means start at offset 0
and just force special behavior).
2020-12-09 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/98199
* fold-const.c (native_encode_initializer): Fix handling bit-fields
when off > 0.
* gcc.c-torture/compile/pr98199.c: New test.
|
|
When native_encode_initializer is called with non-NULL mask (i.e. ATM
bit_cast only), it checks if the current index in the CONSTRUCTOR (if any)
is the next initializable FIELD_DECL, and if not, decrements cnt and
performs the iteration with that FIELD_DECL as field and val of zero
(so that it computes mask properly). As the testcase shows, I forgot to
set pos to the byte position of the field though (like it is done
for e.g. index referenced FIELD_DECLs in the constructor.
2020-12-09 Jakub Jelinek <jakub@redhat.com>
PR c++/98193
* fold-const.c (native_encode_initializer): Set pos to field's
byte position if iterating over a field with missing initializer.
* g++.dg/cpp2a/bit-cast7.C: New test.
|
|
native_encode_initializer [PR93121]
The following testcase is rejected, because when trying to encode a zeroing
CONSTRUCTOR, the code was using build_constructor to build initializers for
the elements but when recursing the function handles CONSTRUCTOR only for
aggregate types.
The following patch fixes that by using build_zero_cst instead for
non-aggregates. Another option would be add handling CONSTRUCTOR for
non-aggregates in native_encode_initializer. Or we can do both, I guess
the middle-end generally doesn't like CONSTRUCTORs for scalar variables, but
am not 100% sure if the FE doesn't produce those sometimes.
2020-12-04 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/93121
* fold-const.c (native_encode_initializer): Use build_zero_cst
instead of build_constructor.
* g++.dg/cpp2a/bit-cast6.C: New test.
|
|
The following patch adds __builtin_bit_cast builtin, similarly to
clang or MSVC which implement std::bit_cast using such an builtin too.
It checks the various std::bit_cast requirements, when not constexpr
evaluated acts pretty much like VIEW_CONVERT_EXPR of the source argument
to the destination type and the hardest part is obviously the constexpr
evaluation.
I've left out PDP11 handling of those, couldn't figure out how exactly are
bitfields laid out there
2020-12-03 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/93121
* fold-const.h (native_encode_initializer): Add mask argument
defaulted to nullptr.
(find_bitfield_repr_type): Declare.
(native_interpret_aggregate): Declare.
* fold-const.c (find_bitfield_repr_type): New function.
(native_encode_initializer): Add mask argument and support for
filling it. Handle also some bitfields without integral
DECL_BIT_FIELD_REPRESENTATIVE.
(native_interpret_aggregate): New function.
* gimple-fold.h (clear_type_padding_in_mask): Declare.
* gimple-fold.c (struct clear_padding_struct): Add clear_in_mask
member.
(clear_padding_flush): Handle buf->clear_in_mask.
(clear_padding_union): Copy clear_in_mask. Don't error if
buf->clear_in_mask is set.
(clear_padding_type): Don't error if buf->clear_in_mask is set.
(clear_type_padding_in_mask): New function.
(gimple_fold_builtin_clear_padding): Set buf.clear_in_mask to false.
* doc/extend.texi (__builtin_bit_cast): Document.
* c-common.h (enum rid): Add RID_BUILTIN_BIT_CAST.
* c-common.c (c_common_reswords): Add __builtin_bit_cast.
* cp-tree.h (cp_build_bit_cast): Declare.
* cp-tree.def (BIT_CAST_EXPR): New tree code.
* cp-objcp-common.c (names_builtin_p): Handle RID_BUILTIN_BIT_CAST.
(cp_common_init_ts): Handle BIT_CAST_EXPR.
* cxx-pretty-print.c (cxx_pretty_printer::postfix_expression):
Likewise.
* parser.c (cp_parser_postfix_expression): Handle
RID_BUILTIN_BIT_CAST.
* semantics.c (cp_build_bit_cast): New function.
* tree.c (cp_tree_equal): Handle BIT_CAST_EXPR.
(cp_walk_subtrees): Likewise.
* pt.c (tsubst_copy): Likewise.
* constexpr.c (check_bit_cast_type, cxx_eval_bit_cast): New functions.
(cxx_eval_constant_expression): Handle BIT_CAST_EXPR.
(potential_constant_expression_1): Likewise.
* cp-gimplify.c (cp_genericize_r): Likewise.
* g++.dg/cpp2a/bit-cast1.C: New test.
* g++.dg/cpp2a/bit-cast2.C: New test.
* g++.dg/cpp2a/bit-cast3.C: New test.
* g++.dg/cpp2a/bit-cast4.C: New test.
* g++.dg/cpp2a/bit-cast5.C: New test.
|
|
The PR38359 change made the -1 >> x to -1 optimization less useful by
requiring that the x must be non-negative.
Shifts by negative amount are UB, but we for historic reasons had in some
(but not all) places some hack to treat shifts by negative value as the
other direction shifts by the negated amount.
The following patch just removes that special handling, instead we punt on
optimizing those (and ideally path isolation should catch that up and turn
those into __builtin_unreachable, perhaps with __builtin_warning next to
it). Folding the shifts in some places as if they were rotates and in other
as if they were saturating just leads to inconsistencies.
For C++ constexpr diagnostics and -fpermissive, I've added code to pretend
fold-const.c has not changed, without -fpermissive it will be an error
anyway and I think it is better not to change all the diagnostics.
During x86_64-linux and i686-linux bootstrap/regtest, my statistics
gathering patch noted 185 unique -m32/-m64 x TU x function_name x shift_kind
x fold-const/tree-ssa-ccp cases. I have investigated the
64 ../../gcc/config/i386/i386.c x86_output_aligned_bss LSHIFT_EXPR wide_int_bitop
64 ../../gcc/config/i386/i386-expand.c emit_memmov LSHIFT_EXPR wide_int_bitop
64 ../../gcc/config/i386/i386-expand.c ix86_expand_carry_flag_compare LSHIFT_EXPR wide_int_bitop
64 ../../gcc/expmed.c expand_divmod LSHIFT_EXPR wide_int_bitop
64 ../../gcc/lra-lives.c process_bb_lives LSHIFT_EXPR wide_int_bitop
64 ../../gcc/rtlanal.c nonzero_bits1 LSHIFT_EXPR wide_int_bitop
64 ../../gcc/varasm.c optimize_constant_pool.isra LSHIFT_EXPR wide_int_bitop
cases and all of them are either during jump threading (dom) or during PRE.
For jump threading, the most common case is 1 << floor_log2 (whatever) where
floor_log2 is return HOST_BITS_PER_WIDE_INT - 1 - clz_hwi (x);
and clz_hwi is if (x == 0) return HOST_BITS_PER_WIDE_INT; return __builtin_clz* (x);
and so has range [-1, 63] and a comparison against == 0 which makes the
threader think it might be nice to jump thread the case leading to 1 << -1.
I think it is better to keep the 1 << -1 s in the IL for this and let path
isolation turn that into __builtin_unreachable () if the user wishes so.
2020-11-24 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/96929
* fold-const.c (wide_int_binop) <case LSHIFT_EXPR, case RSHIFT_EXPR>:
Return false on negative second argument rather than trying to handle
it as shift in the other direction.
* tree-ssa-ccp.c (bit_value_binop) <case LSHIFT_EXPR,
case RSHIFT_EXPR>: Punt on negative shift count rather than trying
to handle it as shift in the other direction.
* match.pd (-1 >> x to -1): Remove tree_expr_nonnegative_p check.
* constexpr.c (cxx_eval_binary_expression): For shifts by constant
with MSB set, emulate older wide_int_binop behavior to preserve
diagnostics and -fpermissive behavior.
* gcc.dg/tree-ssa/pr96929.c: New test.
|
|
* fold-const.c (operand_compare::operand_equal_p): Fix thinko in
COMPONENT_REF handling and guard types_same_for_odr by
virtual_method_call_p.
(operand_compare::hash_operand): Likewise.
|
|
This fixes a typo in the TREE_CODE compare which should
compare against TYPE_DECL, not TYPE_NAME.
2020-11-19 Richard Biener <rguenther@suse.de>
* fold-const.c (operand_compare::hash_operand): Fix typo.
|
|
* fold-const.c (operand_compare::operand_equal_p): More OBJ_TYPE_REF
matching to correct place; drop OEP_ADDRESS_OF for TOKEN, OBJECT and
class.
(operand_compare::hash_operand): Hash ODR type for OBJ_TYPE_REF.
|
|
The motivation for this patch is PR middle-end/85811, a wrong-code
regression entitled "Invalid optimization with fmax, fabs and nan".
The optimization involves assuming max(x,y) is non-negative if (say)
y is non-negative, i.e. max(x,2.0). Unfortunately, this is an invalid
assumption in the presence of NaNs. Hence max(x,+qNaN), with IEEE fmax
semantics will always return x even though the qNaN is non-negative.
Worse, max(x,2.0) may return a negative value if x is -sNaN.
I'll quote Joseph Myers (many thanks) who describes things clearly as:
> (a) When both arguments are NaNs, the return value should be a qNaN,
> but sometimes it is an sNaN if at least one argument is an sNaN.
> (b) Under TS 18661-1 semantics, if either argument is an sNaN then the
> result should be a qNaN (whereas if one argument is a qNaN and the
> other is not a NaN, the result should be the non-NaN argument).
> Various implementations treat sNaNs like qNaNs here.
Under this logic, the tree_expr_nonnegative_p for IEEE fmax should be:
CASE_CFN_FMAX:
CASE_CFN_FMAX_FN:
/* Usually RECURSE (arg0) || RECURSE (arg1) but NaNs complicate
things. In the presence of sNaNs, we're only guaranteed to be
non-negative if both operands are non-negative. In the presence
of qNaNs, we're non-negative if either operand is non-negative
and can't be a qNaN, or if both operands are non-negative. */
if (tree_expr_maybe_signaling_nan_p (arg0) ||
tree_expr_maybe_signaling_nan_p (arg1))
return RECURSE (arg0) && RECURSE (arg1);
return RECURSE (arg0) ? (!tree_expr_maybe_nan_p (arg0)
|| RECURSE (arg1))
: (RECURSE (arg1)
&& !tree_expr_maybe_nan_p (arg1));
Which indeed resolves the wrong code in the PR. The infrastructure that
makes this possible are the two new functions tree_expr_maybe_nan_p and
tree_expr_maybe_signaling_nan_p which test whether a value may potentially
be a NaN or a signaling NaN respectively. In fact, this patch adds seven
new predicates to the middle-end:
bool tree_expr_finite_p (const_tree);
bool tree_expr_infinite_p (const_tree);
bool tree_expr_maybe_infinite_p (const_tree);
bool tree_expr_signaling_nan_p (const_tree);
bool tree_expr_maybe_signaling_nan_p (const_tree);
bool tree_expr_nan_p (const_tree);
bool tree_expr_maybe_nan_p (const_tree);
These functions correspond to the "must" and "may" operators in modal logic,
and allow us to triage expressions in the middle-end; definitely a NaN,
definitely not a NaN, and unknown at compile-time, etc. A prime example of
the utility of these functions is that a IEEE floating point value promoted
from an integer type can't be a NaN or infinite. Hence (double)i+0.0 where
i is an integer can be simplified to (double)i even with -fsignaling-nans.
Currently in GCC optimizations are enabled/disabled based on whether the
expression's type supports NaNs or sNaNs; with these new predicates they
can be controlled by whether the actual operands may or may not be NaNs.
Having added these extremely useful helper functions to the middle-end,
I couldn't help by use then in a few places in fold-const.c, builtins.c
and match.pd. In the near term, these can/should be used in places
where the tree optimizers test for HONOR_NANS, HONOR_INFINITIES or
HONOR_SNANS, or explicitly test whether a REAL_CST is a NaN or Inf.
In the longer term (I'm not volunteering) these predicates could perhaps
be hooked into the middle-end's SSA chaining and/or VRP machinery,
allowing finiteness to propagated around the CFG, much like we
currently propagate value ranges.
This patch has been tested on x86_64-pc-linux-gnu with a "make bootstrap"
and "make -k check".
Ok for mainline?
2020-08-15 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR middle-end/85811
* fold-const.c (tree_expr_finite_p): New function to test whether
a tree expression must be finite, i.e. not a FP NaN or infinity.
(tree_expr_infinite_p): New function to test whether a tree
expression must be infinite, i.e. a FP infinity.
(tree_expr_maybe_infinite_p): New function to test whether a tree
expression may be infinite, i.e. a FP infinity.
(tree_expr_signaling_nan_p): New function to test whether a tree
expression must evaluate to a signaling NaN (sNaN).
(tree_expr_maybe_signaling_nan_p): New function to test whether a
tree expression may be a signaling NaN (sNaN).
(tree_expr_nan_p): New function to test whether a tree expression
must evaluate to a (quiet or signaling) NaN.
(tree_expr_maybe_nan_p): New function to test whether a tree
expression me be a (quiet or signaling) NaN.
(tree_binary_nonnegative_warnv_p) [MAX_EXPR]: In the presence
of NaNs, MAX_EXPR is only guaranteed to be non-negative, if both
operands are non-negative.
(tree_call_nonnegative_warnv_p) [CASE_CFN_FMAX,CASE_CFN_FMAX_FN]:
In the presence of signaling NaNs, fmax is only guaranteed to be
non-negative if both operands are negative. In the presence of
quiet NaNs, fmax is non-negative if either operand is non-negative
and not a qNaN, or both operands are non-negative.
* fold-const.h (tree_expr_finite_p, tree_expr_infinite_p,
tree_expr_maybe_infinite_p, tree_expr_signaling_nan_p,
tree_expr_maybe_signaling_nan_p, tree_expr_nan_p,
tree_expr_maybe_nan_p): Prototype new functions here.
* builtins.c (fold_builtin_classify) [BUILT_IN_ISINF]: Fold to
a constant if argument is known to be (or not to be) an Infinity.
[BUILT_IN_ISFINITE]: Fold to a constant if argument is known to
be (or not to be) finite.
[BUILT_IN_ISNAN]: Fold to a constant if argument is known to be
(or not to be) a NaN.
(fold_builtin_fpclassify): Check tree_expr_maybe_infinite_p and
tree_expr_maybe_nan_p instead of HONOR_INFINITIES and HONOR_NANS
respectively.
(fold_builtin_unordered_cmp): Fold UNORDERED_EXPR to a constant
when its arguments are known to be (or not be) NaNs. Check
tree_expr_maybe_nan_p instead of HONOR_NANS when choosing between
unordered and regular forms of comparison operators.
* match.pd (ordered(x,y)->true/false): Constant fold ORDERED_EXPR
if its operands are known to be (or not to be) NaNs.
(unordered(x,y)->true/false): Constant fold UNORDERED_EXPR if its
operands are known to be (or not to be) NaNs.
(sqrt(x)*sqrt(x)->x): Check tree_expr_maybe_signaling_nan_p instead
of HONOR_SNANS.
gcc/testsuite/ChangeLog
PR middle-end/85811
* gcc.dg/pr85811.c: New test.
* gcc.dg/fold-isfinite-1.c: New test.
* gcc.dg/fold-isfinite-2.c: New test.
* gcc.dg/fold-isinf-1.c: New test.
* gcc.dg/fold-isinf-2.c: New test.
* gcc.dg/fold-isnan-1.c: New test.
* gcc.dg/fold-isnan-2.c: New test.
|
|
* fold-const.c (operand_compare::operand_equal_p): Compare field
offsets in operand_equal_p and OEP_ADDRESS_OF.
(operand_compare::hash_operand): Update.
|
|
This removes a duplicated statement.
It was apparently introduced due to a merge mistake.
2020-11-03 Bernd Edlinger <bernd.edlinger@hotmail.de>
* fold-const.c (getbyterep): Remove duplicated statement.
|
|
split_constant_offset is confused about a nop-conversion from
unsigned long to sizetype and tries to prove non-overflowing
of the inner operation. Obviously the conversion could have been
elided so make sure split_constant_offset handles this properly.
It also makes sure that convert_to_ptrofftype does not introduce
conversions not necessary which in this case is the source for
the unnecessary conversion.
2020-10-15 Richard Biener <rguenther@suse.de>
PR tree-optimization/97482
* tree-data-ref.c (split_constant_offset_1): Handle
trivial conversions better.
* fold-const.c (convert_to_ptrofftype_loc): Elide conversion
if the offset is already ptrofftype_p.
* gcc.dg/vect/pr97428.c: New testcase.
|
|
This improves the situation somewhat when vector lowering tries
to access vector bools as seen in PR96814.
2020-09-03 Richard Biener <rguenther@suse.de>
* tree-vect-generic.c (tree_vec_extract): Remove odd
special-casing of boolean vectors.
* fold-const.c (fold_ternary_loc): Handle boolean vector
type BIT_FIELD_REFs.
|
|
PR tree-optimization/21137 is now an old enhancement request pointing out
that an optimization I added back in 2006, to optimize "((x>>31)&64) != 0"
as "x < 0", doesn't fire in the presence of unanticipated type conversions.
The fix is to call STRIP_NOPS at the appropriate point.
2020-08-25 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR tree-optimization/21137
* fold-const.c (fold_binary_loc) [NE_EXPR/EQ_EXPR]: Call
STRIP_NOPS when checking whether to simplify ((x>>C1)&C2) != 0.
gcc/testsuite/ChangeLog
PR tree-optimization/21137
* gcc.dg/pr21137.c: New test.
|
|
My patch to introduce native_encode_initializer to fold_ctor_reference
apparently broke gnulib/m4 on powerpc64.
There it uses a const union with two doubles and corresponding IBM double
double long double which actually is the largest normalizable long double
value (1 ulp higher than __LDBL_MAX__). The reason our __LDBL_MAX__ is
smaller is that we internally treat the double double type as one having
106-bit precision, but it actually has a variable 53-bit to 2000-ish bit precision
and for the
0x1.fffffffffffff7ffffffffffffc000p+1023L
value gnulib uses we need 107-bit precision, therefore for GCC __LDBL_MAX__
is
0x1.fffffffffffff7ffffffffffff8000p+1023L
Before my changes, we wouldn't be able to fold_ctor_reference it and it
worked fine at runtime, but with the change we are able to do that, but
because it is larger than anything we can handle internally, we treat it
weirdly. Similar problem would be if somebody creates this way valid,
but much more than 106 bit precision e.g. 1.0 + 1.0e-768.
Now, I think similar problem could happen e.g. on i?86/x86_64 with long
double there, it also has some weird values in the format, e.g. the
unnormals, pseudo infinities and various other magic values.
This patch for floating point types (including vector and complex types
with such elements) will try to encode the returned value again and punt
if it has different memory representation from the original. Note, this
is only done in the path where native_encode_initializer was used, in order
not to affect e.g. just reading an unpunned long double value; the value
should be compiler generated in that case and thus should be properly
representable. It will punt also if e.g. the padding bits are initialized
to non-zero values.
I think the verification that what we encode can be interpreted back
woiuld be only an internal consistency check (so perhaps for ENABLE_CHECKING
if flag_checking only, but if both directions perform it, then we need
to avoid mutual recursion).
While for the other direction (interpretation), at least for the broken by
design long doubles we just know we can't represent in GCC all valid values.
The other floating point formats are just theoretical case, perhaps we would
canonicalize something to a value that wouldn't trigger invalid exception
when without canonicalization it would trigger it at runtime, so let's just
ignore those.
Adjusted (so far untested) patch to do it in native_interpret_real instead
and limit it to the MODE_COMPOSITE_P cases, for which e.g.
fold-const.c/simplify-rtx.c punts in several other places too because we just
know we can't represent everything.
E.g.
/* Don't constant fold this floating point operation if the
result may dependent upon the run-time rounding mode and
flag_rounding_math is set, or if GCC's software emulation
is unable to accurately represent the result. */
if ((flag_rounding_math
|| (MODE_COMPOSITE_P (mode) && !flag_unsafe_math_optimizations))
&& (inexact || !real_identical (&result, &value)))
return NULL_TREE;
Or perhaps guard it with MODE_COMPOSITE_P (mode) && !flag_unsafe_math_optimizations
too, thus break what gnulib / m4 does with -ffast-math, but not normally?
2020-08-25 Jakub Jelinek <jakub@redhat.com>
PR target/95450
* fold-const.c (native_interpret_real): For MODE_COMPOSITE_P modes
punt if the to be returned REAL_CST does not encode to the bitwise
same representation.
* gcc.target/powerpc/pr95450.c: New test.
|
|
gcc/ChangeLog:
* fold-const.c (native_encode_expr): Update comment.
|
|
gcc/ChangeLog:
PR middle-end/78257
* builtins.c (expand_builtin_memory_copy_args): Rename called function.
(expand_builtin_stpcpy_1): Remove argument from call.
(expand_builtin_memcmp): Rename called function.
(inline_expand_builtin_bytecmp): Same.
* expr.c (convert_to_bytes): New function.
(constant_byte_string): New function (formerly string_constant).
(string_constant): Call constant_byte_string.
(byte_representation): New function.
* expr.h (byte_representation): Declare.
* fold-const-call.c (fold_const_call): Rename called function.
* fold-const.c (c_getstr): Remove an argument.
(getbyterep): Define a new function.
* fold-const.h (c_getstr): Remove an argument.
(getbyterep): Declare a new function.
* gimple-fold.c (gimple_fold_builtin_memory_op): Rename callee.
(gimple_fold_builtin_string_compare): Same.
(gimple_fold_builtin_memchr): Same.
gcc/testsuite/ChangeLog:
PR middle-end/78257
* gcc.dg/memchr.c: New test.
* gcc.dg/memcmp-2.c: New test.
* gcc.dg/memcmp-3.c: New test.
* gcc.dg/memcmp-4.c: New test.
|
|
gcc/ChangeLog:
* fold-const.c (expr_not_equal_to): Adjust for irange API.
|
|
This makes the special case of constant evaluated LHS for a
short-circuiting or/and explicit rather than doing range
merging and eventually exposing a side-effect that shouldn't be
evaluated.
2020-07-31 Richard Biener <rguenther@suse.de>
PR middle-end/96369
* fold-const.c (fold_range_test): Special-case constant
LHS for short-circuiting operations.
* c-c++-common/pr96369.c: New testcase.
|
|
Resolves:
PR middle-end/95189 - memcmp being wrongly stripped like strcm
PR middle-end/95886 - suboptimal memcpy with embedded zero bytes
gcc/ChangeLog:
PR middle-end/95189
PR middle-end/95886
* builtins.c (inline_expand_builtin_string_cmp): Rename...
(inline_expand_builtin_bytecmp): ...to this.
(builtin_memcpy_read_str): Don't expect data to be nul-terminated.
(expand_builtin_memory_copy_args): Handle object representations
with embedded nul bytes.
(expand_builtin_memcmp): Same.
(expand_builtin_strcmp): Adjust call to naming change.
(expand_builtin_strncmp): Same.
* expr.c (string_constant): Create empty strings with nonzero size.
* fold-const.c (c_getstr): Rename locals and update comments.
* tree.c (build_string): Accept null pointer argument.
(build_string_literal): Same.
* tree.h (build_string): Provide a default.
(build_string_literal): Same.
gcc/testsuite/ChangeLog:
PR middle-end/95189
PR middle-end/95886
* gcc.dg/memcmp-pr95189.c: New test.
* gcc.dg/strncmp-3.c: New test.
* gcc.target/i386/memcpy-pr95886.c: New test.
|
|
When working on __builtin_bit_cast that needs to handle bitfields too,
I've made the following change to handle at least some bitfields in
native_encode_initializer (those that have integral representative).
2020-07-20 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/93121
* fold-const.c (native_encode_initializer): Handle bit-fields.
* gcc.dg/tree-ssa/pr93121-1.c: New test.
|
|
We folded A <= 0 ? A : -A into -ABS (A), which is for signed integral types
incorrect - can invoke on INT_MIN UB twice, once on ABS and once on its
negation.
The following patch fixes it by instead folding it to (type)-ABSU (A).
2020-06-24 Jakub Jelinek <jakub@redhat.com>
PR middle-end/95810
* fold-const.c (fold_cond_expr_with_comparison): Optimize
A <= 0 ? A : -A into (type)-absu(A) rather than -abs(A).
* gcc.dg/ubsan/pr95810.c: New test.
|
|
This patch introduces a new builtin named __builtin_bswap128 on targets
where TImode is supported, i.e. 64-bit targets only in practice. The
implementation simply reuses the existing double word path in optab, so
no routine is added to libgcc (which means that you get two calls to
_bswapdi2 in the worst case).
gcc/ChangeLog:
* builtin-types.def (BT_UINT128): New primitive type.
(BT_FN_UINT128_UINT128): New function type.
* builtins.def (BUILT_IN_BSWAP128): New GCC builtin.
* doc/extend.texi (__builtin_bswap128): Document it.
* builtins.c (expand_builtin): Deal with BUILT_IN_BSWAP128.
(is_inexpensive_builtin): Likewise.
* fold-const-call.c (fold_const_call_ss): Likewise.
* fold-const.c (tree_call_nonnegative_warnv_p): Likewise.
* tree-ssa-ccp.c (evaluate_stmt): Likewise.
* tree-vect-stmts.c (vect_get_data_ptr_increment): Likewise.
(vectorizable_call): Likewise.
* optabs.c (expand_unop): Always use the double word path for it.
* tree-core.h (enum tree_index): Add TI_UINT128_TYPE.
* tree.h (uint128_type_node): New global type.
* tree.c (build_common_tree_nodes): Build it if TImode is supported.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-bswap-10.c: New test.
* gcc.dg/builtin-bswap-11.c: Likewise.
* gcc.dg/builtin-bswap-12.c: Likewise.
* gcc.target/i386/builtin-bswap-5.c: Likewise.
|
|
[PR94718]
This patch moves this optimization from fold-const.c to match.pd where it
is actually much shorter to do and lets optimize even code not seen together
in a single expression in the source, as the first step towards fixing the
PR.
2020-05-04 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/94718
* fold-const.c (fold_binary_loc): Move (X & C) eqne (Y & C)
-> (X ^ Y) & C eqne 0 optimization to ...
* match.pd ((X & C) op (Y & C) into (X ^ Y) & C op 0): ... here.
* gcc.dg/tree-ssa/pr94718-1.c: New test.
* gcc.dg/tree-ssa/pr94718-2.c: New test.
|
|
The following testcase is miscompiled since 4.9, we treat unsigned
vector types as if they were signed and "optimize" negations across it.
2020-03-31 Marc Glisse <marc.glisse@inria.fr>
Jakub Jelinek <jakub@redhat.com>
PR middle-end/94412
* fold-const.c (fold_binary_loc) <case TRUNC_DIV_EXPR>: Use
ANY_INTEGRAL_TYPE_P instead of INTEGRAL_TYPE_P.
* gcc.c-torture/execute/pr94412.c: New test.
Co-authored-by: Marc Glisse <marc.glisse@inria.fr>
|
|
2020-03-19 Richard Biener <rguenther@suse.de>
PR middle-end/94216
* fold-const.c (fold_binary_loc): Avoid using
build_fold_addr_expr when we really want an ADDR_EXPR.
* g++.dg/torture/pr94216.C: New testcase.
|
|
This adds a missing type conversion to build_fold_addr_expr and adjusts
fallout - build_fold_addr_expr was used as a convenience to build an
ADDR_EXPR but some callers do not expect the result to be simplified
to something else.
2020-03-18 Richard Biener <rguenther@suse.de>
PR middle-end/94188
* fold-const.c (build_fold_addr_expr): Convert address to
correct type.
* asan.c (maybe_create_ssa_name): Strip useless type conversions.
* gimple-fold.c (gimple_fold_stmt_to_constant_1): Use build1
to build the ADDR_EXPR which we don't really want to simplify.
* tree-ssa-dom.c (record_equivalences_from_stmt): Likewise.
* tree-ssa-loop-im.c (gather_mem_refs_stmt): Likewise.
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Likewise.
(simplify_builtin_call): Strip useless type conversions.
* tree-ssa-strlen.c (new_strinfo): Likewise.
* gcc.dg/pr94188.c: New testcase.
|
