In my previous change I mistakenly changed Value_Range to
int_range<2>. The former has "infinite" precision for integer ranges,
whereas int_range<2> has two sub-ranges. This should have been
int_range_max.
gcc/ChangeLog:
* gimple-ssa-warn-access.cc (check_nul_terminated_array): Change
int_range<2> to int_range_max.
(memmodel_to_uhwi): Same.
* tree-ssa-loop-niter.cc (refine_value_range_using_guard): Same.
(determine_value_range): Same.
(infer_loop_bounds_from_signedness): Same.
(scev_var_range_cant_overflow): Same.
A large number of gm2 tests are timing out even on current Solaris/SPARC
systems. As detailed in the PR, the problem is that the gm2 testsuite
artificially lowers many timeouts way below the DejaGnu default of 300
seconds, often as short as 10 seconds. The problem lies both in the
values (they may be appropriate for some targets, but too low for
others, especially under high load) and the fact that it uses absolute
values, overriding e.g. settings from a build-wide site.exp.
Therefore this patch removes all those overrides, restoring the
defaults.
Tested on sparc-sun-solaris2.11 (where all the previous timeouts are
gone) and i386-pc-solaris2.11.
2024-04-29 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
PR modula2/114886
* lib/gm2.exp: Don't load timeout-dg.exp.
Don't set gm2_previous_timeout.
Don't call dg-timeout.
(gm2_push_timeout, gm2_pop_timeout): Remove.
(gm2_init): Don't call dg-timeout.
* lib/gm2-torture.exp: Don't load timeout-dg.exp.
Don't set gm2_previous_timeout.
Don't call dg-timeout.
(gm2_push_timeout, gm2_pop_timeout): Remove.
* gm2/coroutines/pim/run/pass/coroutines-pim-run-pass.exp: Don't
load timeout-dg.exp.
Don't call gm2_push_timeout, gm2_pop_timeout.
* gm2/examples/map/pass/examples-map-pass.exp: Don't call
gm2_push_timeout, gm2_pop_timeout.
* gm2/iso/run/pass/iso-run-pass.exp: Don't load timeout-dg.exp.
Don't call gm2_push_timeout, gm2_pop_timeout.
* gm2/pimlib/base/run/pass/pimlib-base-run-pass.exp: Don't load
timeout-dg.exp.
Don't call gm2_push_timeout, gm2_pop_timeout.
* gm2/projects/iso/run/pass/halma/projects-iso-run-pass-halma.exp:
Don't call gm2_push_timeout, gm2_pop_timeout.
* gm2/switches/whole-program/pass/run/switches-whole-program-pass-run.exp:
Don't load timeout-dg.exp.
Don't call gm2_push_timeout, gm2_pop_timeout.
The following adds support for the various division and modulo operators
to the GIMPLE frontend via __{CEIL,FLOOR,ROUND}_{DIV,MOD} and
__EXACT_DIV operators.
gcc/c/
* gimple-parser.cc (c_parser_gimple_binary_expression):
Parse __{CEIL,FLOOR,ROUND}_{DIV,MOD} and __EXACT_DIV.
gcc/testsuite/
* gcc.dg/gimplefe-53.c: New testcase.
Currently we expand POINTER_DIFF_EXPR using subv_optab when -ftrapv
(but -fsanitize=undefined does nothing). That's not consistent
with the behavior of POINTER_PLUS_EXPR which never uses addv_optab
with -ftrapv. Both are because of the way we select whether to use
the trapping or the non-trapping optab - we look at the result type
of the expression and check
trapv = INTEGRAL_TYPE_P (type) && TYPE_OVERFLOW_TRAPS (type);
the bugreport correctly complains that -ftrapv affects pointer
subtraction (there's no -ftrapv-pointer). Now that we have
POINTER_DIFF_EXPR we can honor that appropriately.
The patch moves both POINTER_DIFF_EXPR and POINTER_PLUS_EXPR
handling so they will never consider trapping (or saturating)
optabs.
PR middle-end/13421
* optabs-tree.cc (optab_for_tree_code): Do not consider
{add,sub}v or {us,ss}{add,sub} optabs for POINTER_DIFF_EXPR
or POINTER_PLUS_EXPR.
Seems when Martin S. implemented this, he coded there strict reading
of the standard, which said that %lc with (wint_t) 0 argument is handled
as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
any values. But, most of the libc implementations actually handled that
case like %c with '\0' argument, adding a single NUL character, the only
known exception is musl.
Recently, C23 changed this in response to GB-141 and POSIX in
https://austingroupbugs.net/view.php?id=1647
so that it should have the same behavior as %c with '\0'.
Because there is implementation divergence, the following patch uses
a range rather than hardcoding it to all 1s (i.e. the %c behavior),
though the likely case is still 1 (forward looking plus most of
implementations).
The res.knownrange = true; assignment removed is redundant due to
the same assignment done unconditionally before the if statement,
rest is formatting fixes.
I don't think the min >= 0 && min < 128 case is right either, I'd think
it should be min >= 0 && max < 128, otherwise it is just some possible
inputs are (maybe) ASCII and there can be others, but this code is a total
mess anyway, with the min, max, likely (somewhere in [min, max]?) and then
unlikely possibly larger than max, dunno, perhaps for at least some chars
in the ASCII range the likely case could be for the ascii case; so perhaps
just the one_2_one_ascii shouldn't set max to 1 and mayfail should be true
for max >= 128. Anyway, didn't feel I should touch that right now.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/114876
* gimple-ssa-sprintf.cc (format_character): For min == 0 && max == 0,
set max, likely and unlikely members to 1 rather than 0. Remove
useless res.knownrange = true;. Formatting fixes.
* gcc.dg/pr114876.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected
diagnostics.
GDB emits end of lines as \r\n, we currently match any >0 number of
either \n or \r, possibly leading to mismatches under racy conditions.
I noticed this while running the GCC testsuite using the equivalent of
GDB's READ1 feature [1] which helps detecting bufferization issues.
We try to match
\n$1 = empty std::tuple\r
against {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} which fails because
of the leading \n (which was left in the buffer after the previous
"skipping" pattern matched the preceding \r).
This patch accepts any number of leading \n and/or \r in the "got" clause.
Also take this opportunity to quote \r and \r in the logs, to make
debugging such issues easier.
Tested on aarch64-linux-gnu.
[1] https//github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
2024-01-24 Christophe Lyon <christophe.lyon@linaro.org>
libstdc++-v3/
* testsuite/lib/gdb-test.exp (gdb-test): Fix regexp. Quote
newlines in logs.
The assertion doesn't allow IFN_COND_MIN/IFN_COND_MAX, which are
commutative conditional binary operations like ADD/MUL/AND/IOR/XOR,
and can be handled just fine.
In particular, we emit
vminpd %zmm3, %zmm5, %zmm0{%k2}
vminpd %zmm0, %zmm3, %zmm5{%k1}
and
vmaxpd %zmm3, %zmm5, %zmm0{%k2}
vmaxpd %zmm0, %zmm3, %zmm5{%k1}
in the vectorized loops of the first and second subroutine.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
Hongtao Liu <hongtao.liu@intel.com>
PR tree-optimization/114883
* tree-vect-loop.cc (vect_transform_reduction): Allow IFN_COND_MIN and
IFN_COND_MAX in the assert.
* gfortran.dg/pr114883.f90: New test.
On Mon, Apr 29, 2024 at 01:44:24PM +0000, Joseph Myers wrote:
> > glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
> > dummy shared library with just some symbol versions for compatibility, but
> > all the pthread_* APIs are in libc.so.6).
>
> I suspect this has caused link failures in the glibc testsuite for Hurd,
> which still has separate libpthread.
>
> https://sourceware.org/pipermail/libc-testresults/2024q2/012556.html
So like this then?
2024-04-30 Jakub Jelinek <jakub@redhat.com>
* gthr.h (GTHREAD_USE_WEAK): Don't redefine to 0 for glibc 2.34+
on GNU Hurd.
While the C23 standard isn't officially release yet,
in 2011 we've changed __STDC_VERSION__ value for C11 already
in the month in which the new __STDC_VERSION__ value has been
finalized, so we want to change this now or wait
until we implement all the C23 features?
Note, seems Clang up to 17 also used 202000L for -std=c2x but
Clang 18+ uses 202311L as specified in the latest C23 drafts.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
* init.cc (cpp_init_builtins): Change __STDC_VERSION__
for C23 from 202000L to 202311L.
* doc/cpp.texi (__STDC_VERSION__): Document 202311L value
for -std=c23/-std=gnu23.
The following patch implements the P0609R3 paper; we build the
VAR_DECLs for the structured binding identifiers early, so all we need
IMHO is just to parse the attributed identifier list and pass the attributes
to the VAR_DECL creation.
The paper mentions maybe_unused and gnu::nonstring attributes as examples
where they can be useful. Not sure about either of them.
For maybe_unused, the thing is that both GCC and clang already don't
diagnose maybe unused for the structured binding identifiers, because it
would be a false positive too often; and there is no easy way to find out
if a structured binding has been written with the P0609R3 paper in mind or
not (maybe we could turn it on if in the structured binding is any
attribute, even if just [[]] and record that as a flag on the whole
underlying decl, so that we'd diagnose
auto [a, b, c[[]]] = d;
// use a, c but not b
but not
auto [e, f, g] = d;
// use a, c but not b
). For gnu::nonstring, the issue is that we currently don't allow the
attribute on references to char * or references to char[], just on
char */char[]. I've filed a PR for that.
The first testcase in the patch tests it on [[]] and [[maybe_unused]],
just whether it is parsed properly, second on gnu::deprecated, which
works. Haven't used deprecated attribute because the paper said that
attribute is for further investigation.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
PR c++/114456
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_structured_bindings for C++26 to 202403L rather than
201606L.
gcc/cp/
* parser.cc (cp_parser_decomposition_declaration): Implement C++26
P0609R3 - Attributes for Structured Bindings. Parse attributed
identifier lists for structured binding declarations, pass the
attributes to start_decl.
gcc/testsuite/
* g++.dg/cpp26/decomp1.C: New test.
* g++.dg/cpp26/decomp2.C: New test.
* g++.dg/cpp26/feat-cxx26.C (__cpp_structured_bindings): Expect
202403 rather than 201606.
When expand_call_mem_ref looks at the definition of the address
argument to eventually expand a &TARGET_MEM_REF argument together
with a masked load it fails to honor constraints imposed by SSA
coalescing decisions. The following fixes this.
PR middle-end/114734
* internal-fn.cc (expand_call_mem_ref): Use
get_gimple_for_ssa_name to get at the def stmt of the address
argument to honor SSA coalescing constraints.
This patch fixes a number of issues with the handling of temploid friend
declarations.
The primary issue is that instantiations of friend declarations should
attach the declaration to the same module as the befriending class, by
[module.unit] p7.1 and [temp.friend] p2; this could be a different
module from the current TU, and so needs special handling.
The other main issue here is that we can't assume that just because name
lookup didn't find a definition for a hidden class template, that it
doesn't exist at all: it could be a non-exported entity that we've
nevertheless streamed in from an imported module. We need to ensure
that when instantiating template friend classes that we return the same
TEMPLATE_DECL that we got from our imports, otherwise we will get later
issues with 'duplicate_decls' (rightfully) complaining that they're
different when trying to merge.
This doesn't appear necessary for function templates due to the existing
name lookup handling already finding these hidden declarations.
PR c++/105320
PR c++/114275
gcc/cp/ChangeLog:
* cp-tree.h (propagate_defining_module): Declare.
(lookup_imported_hidden_friend): Declare.
* decl.cc (duplicate_decls): Also check if hidden decls can be
redeclared in this module.
* module.cc (imported_temploid_friends): New.
(init_modules): Initialize it.
(trees_out::decl_value): Write it; don't consider imported
temploid friends as attached to a module.
(trees_in::decl_value): Read it.
(get_originating_module_decl): Follow the owning decl for an
imported temploid friend.
(propagate_defining_module): New.
* name-lookup.cc (get_mergeable_namespace_binding): New.
(lookup_imported_hidden_friend): New.
* pt.cc (tsubst_friend_function): Propagate defining module for
new friend functions.
(tsubst_friend_class): Lookup imported hidden friends. Check
for valid module attachment of existing names. Propagate
defining module for new classes.
gcc/testsuite/ChangeLog:
* g++.dg/modules/tpl-friend-10_a.C: New test.
* g++.dg/modules/tpl-friend-10_b.C: New test.
* g++.dg/modules/tpl-friend-10_c.C: New test.
* g++.dg/modules/tpl-friend-10_d.C: New test.
* g++.dg/modules/tpl-friend-11_a.C: New test.
* g++.dg/modules/tpl-friend-11_b.C: New test.
* g++.dg/modules/tpl-friend-12_a.C: New test.
* g++.dg/modules/tpl-friend-12_b.C: New test.
* g++.dg/modules/tpl-friend-12_c.C: New test.
* g++.dg/modules/tpl-friend-12_d.C: New test.
* g++.dg/modules/tpl-friend-12_e.C: New test.
* g++.dg/modules/tpl-friend-12_f.C: New test.
* g++.dg/modules/tpl-friend-13_a.C: New test.
* g++.dg/modules/tpl-friend-13_b.C: New test.
* g++.dg/modules/tpl-friend-13_c.C: New test.
* g++.dg/modules/tpl-friend-13_d.C: New test.
* g++.dg/modules/tpl-friend-13_e.C: New test.
* g++.dg/modules/tpl-friend-13_f.C: New test.
* g++.dg/modules/tpl-friend-13_g.C: New test.
* g++.dg/modules/tpl-friend-14_a.C: New test.
* g++.dg/modules/tpl-friend-14_b.C: New test.
* g++.dg/modules/tpl-friend-14_c.C: New test.
* g++.dg/modules/tpl-friend-14_d.C: New test.
* g++.dg/modules/tpl-friend-9.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
Currently different places calling 'module_may_redeclare' all emit very
similar but slightly different error messages, and handle different
kinds of declarations differently. This patch makes the function
perform its own error messages so that they're all in one place, and
prepares it for use with temploid friends.
gcc/cp/ChangeLog:
* cp-tree.h (module_may_redeclare): Add default parameter.
* decl.cc (duplicate_decls): Don't emit errors for failed
module_may_redeclare.
(xref_tag): Likewise.
(start_enum): Likewise.
* semantics.cc (begin_class_definition): Likewise.
* module.cc (module_may_redeclare): Clean up logic. Emit error
messages on failure.
gcc/testsuite/ChangeLog:
* g++.dg/modules/enum-12.C: Update error message.
* g++.dg/modules/friend-5_b.C: Likewise.
* g++.dg/modules/shadow-1_b.C: Likewise.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
When adding to CLASSTYPE_BEFRIENDING_CLASSES as part of installing an
imported class definition, we need to look through TEMPLATE_DECL like
make_friend_class does.
Otherwise in the below testcase we won't add _Hashtable<int, int> to
CLASSTYPE_BEFRIENDING_CLASSES of _Map_base, which leads to a bogus
access check failure for _M_hash_code.
PR c++/114889
gcc/cp/ChangeLog:
* module.cc (trees_in::read_class_def): Look through
TEMPLATE_DECL when adding to CLASSTYPE_BEFRIENDING_CLASSES.
gcc/testsuite/ChangeLog:
* g++.dg/modules/friend-8_a.H: New test.
* g++.dg/modules/friend-8_b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
In the sizeof / sizeof operator expression handling we're missing
a dependence check for the second operand.
PR c++/114888
gcc/cp/ChangeLog:
* typeck.cc (cp_build_binary_op) <case *_DIV_*>: Add missing
dependence check for the second sizeof operand.
gcc/testsuite/ChangeLog:
* g++.dg/template/sizeof19.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
gcc/fortran/ChangeLog:
* iso-fortran-env.def: Add logical{8,16,32,64} and
real16 named constants.
gcc/testsuite/ChangeLog:
* gfortran.dg/iso_fortran_env_8.f90: New test.
* gfortran.dg/iso_fortran_env_9.f90: New test.
This patch updates the Solaris baselines for the GLIBCXX_3.4.33 version
added in GCC 14.0.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
each), together with the GLIBCXX_3.4.32 update, on both gcc-14 branch
and trunk.
2024-04-28 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.
(cherry picked from commit 330c04dc53)
This patch updates the Solaris baselines for the GLIBCXX_3.4.32 version
added in GCC 13.2.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
each) on the gcc-13 branch and (together with the GLIBCXX_3.4.33 update)
on both gcc-14 branch and trunk.
2024-04-28 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.
(cherry picked from commit 3e1ca51284)
The adjacent_dr_p is sufficient and unnecessary condition for contiguous access.
So unnecessary live-ranges are added and result in smaller LMUL.
This patch uses MEMORY_ACCESS_TYPE as condition and constrains segment
load/store.
Tested on RV64 and no regression.
PR target/114506
gcc/ChangeLog:
* config/riscv/riscv-vector-costs.cc (non_contiguous_memory_access_p): Rename
(need_additional_vector_vars_p): Rename and refine condition
gcc/testsuite/ChangeLog:
* gcc.dg/vect/costmodel/riscv/rvv/pr114506.c: New test.
Signed-off-by: demin.han <demin.han@starfivetech.com>
2024-04-29 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/114959
* trans-expr.cc (gfc_trans_class_init_assign): Return NULL_TREE
if the default initializer has all NULL fields. Guard this
by a requirement that the code not be EXEC_INIT_ASSIGN and that
the object be an INTENT_OUT dummy.
* trans-stmt.cc (gfc_trans_allocate): Change the initializer
code for allocate with mold to EXEC_ALLOCATE to allow an
initializer with all NULL fields.
gcc/testsuite/
PR fortran/114959
* gfortran.dg/pr114959.f90: New test.
When we build with isl, there will be a ICE for graphite in both
the c/c++ and fortran. The legitimize move cannot take care of
below rtl.
(set (subreg:DI (reg:TI 237) 8) (subreg:DI (const_poly_int:TI [4, 2]) 8))
Then we will have ice similar to below:
internal compiler error: in extract_insn, at recog.cc:2812.
This patch would like to take care of the above rtl. Given the value of
const_poly_int can hardly excceed the max of int64, we can simply
consider the highest 8 bytes of TImode is zero and then set the dest
to (const_int 0).
The below test cases are fixed by this PATCH.
C:
FAIL: gcc.dg/graphite/pr111878.c (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: gcc.dg/graphite/pr111878.c (test for excess errors)
Fortran:
FAIL: gfortran.dg/graphite/vect-pr40979.f90 -O (internal compiler
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (internal
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -g (test for excess
errors)
FAIL: gfortran.dg/graphite/pr14741.f90 -O (test for excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for
excess errors)
FAIL: gfortran.dg/graphite/vect-pr40979.f90 -O (test for excess
errors)
FAIL: gfortran.dg/graphite/id-27.f90 -O (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -g (internal compiler
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -g (test for excess
errors)
FAIL: gfortran.dg/graphite/id-27.f90 -O (test for excess errors)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for
excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (internal
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr14741.f90 -O (internal compiler error:
in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -g (internal compiler
error: in extract_insn, at recog.cc:2812)
The below test suites are passed for this patch:
* The rv64gcv fully regression test.
* The rv64gc fully regression test.
Try to write some RTL code for test but not works well according to
existing test cases. Thus, take above as test cases. Please note
graphite require the gcc build with isl.
PR target/114885
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimize_subreg_const_poly_move): New
func impl to take care of (const_int_poly:TI 8).
(riscv_legitimize_move): Handle subreg is const_int_poly,
Signed-off-by: Pan Li <pan2.li@intel.com>
The extension parsing table entries for a range of Zic* extensions
does not match the mask definition in riscv.opt.
This results in broken TARGET_ZIC* macros, because the values of
riscv_zi_subext and riscv_zicmo_subext are set wrong.
This patch fixes this by moving Zic64b into riscv_zicmo_subext
and all other affected Zic* extensions to riscv_zi_subext.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Move ziccamoa, ziccif,
zicclsm, and ziccrse into riscv_zi_subext.
* config/riscv/riscv.opt: Define MASK_ZIC64B for
riscv_ziccmo_subext.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
This patch adds the smin/smax RTL mode for the
min/max.fmt instructions.
Also, since the min/max.fmt instrucions applies to the
IEEE 754-2008 "minNum" and "maxNum" operations, this
patch also provides the new "fmin<mode>3" and
"fmax<mode>3" modes.
gcc/ChangeLog:
* config/mips/i6400.md (i6400_fpu_minmax): New
define_insn_reservation.
* config/mips/mips.h (ISA_HAS_FMIN_FMAX): Define new macro.
* config/mips/mips.md (UNSPEC_FMIN): New unspec.
(UNSPEC_FMAX): Same as above.
(type): Add fminmax.
(smin<mode>3): Generates MIN.fmt instructions.
(smax<mode>3): Generates MAX.fmt instructions.
(fmin<mode>3): Generates MIN.fmt instructions.
(fmax<mode>3): Generates MAX.fmt instructions.
* config/mips/p6600.md (p6600_fpu_fabs): Include fminmax
type.
gcc/testsuite/ChangeLog:
* gcc.target/mips/mips-minmax1.c: New test for MIPS R6.
* gcc.target/mips/mips-minmax2.c: Same as above.
As per the documentation, irange_bitmask must have the unknown bits in
the mask set to 0 in the value field. Even though we say we must have
normalized value/mask bits, we don't enforce it, opting to normalize
on the fly in union and intersect. Avoiding this lazy enforcing as
well as the extra saving/restoring involved in returning the changed
status, gives us a performance increase of 1.25% for VRP and 1.51% for
ipa-CP.
gcc/ChangeLog:
* tree-ssa-ccp.cc (ccp_finalize): Normalize before calling
set_bitmask.
* value-range.cc (irange::intersect_bitmask): Calculate changed
irange_bitmask bits on our own.
(irange::union_bitmask): Same.
(irange_bitmask::verify_mask): Verify that bits are normalized.
* value-range.h (irange_bitmask::union_): Do not normalize.
Remove return value.
(irange_bitmask::intersect): Same.
Remove legacy range_zero and range_nonzero as they return by value,
which make it not work in a separate irange and prange world. Also,
we already have set_zero and set_nonzero methods in vrange.
gcc/ChangeLog:
* range-op-ptr.cc (pointer_plus_operator::wi_fold): Use method
range setters instead of out of line functions.
(pointer_min_max_operator::wi_fold): Same.
(pointer_and_operator::wi_fold): Same.
(pointer_or_operator::wi_fold): Same.
* range-op.cc (operator_negate::fold_range): Same.
(operator_addr_expr::fold_range): Same.
(range_op_cast_tests): Same.
* range.cc (range_zero): Remove.
(range_nonzero): Remove.
* range.h (range_zero): Remove.
(range_nonzero): Remove.
* value-range.cc (range_tests_misc): Use method instead of out of
line function.
Move some code out of the irange pretty printers so it can be shared
with pointers.
gcc/ChangeLog:
* value-range-pretty-print.cc (print_int_bound): New.
(print_irange_bitmasks): New.
(vrange_printer::print_irange_bound): Remove.
(vrange_printer::print_irange_bitmasks): Remove.
* value-range-pretty-print.h: Remove print_irange_bitmasks and
print_irange_bound
There are some irange uses that should be Value_Range, because they
can be either integers or pointers. This will become a problem when
prange comes live.
gcc/ChangeLog:
* tree-ssa-loop-split.cc (split_at_bb_p): Make int_range a Value_Range.
* tree-ssa-strlen.cc (get_range): Same.
* value-query.cc (range_query::get_tree_range): Handle both
integers and pointers.
* vr-values.cc (simplify_using_ranges::fold_cond_with_ops): Make
r0 and r1 Value_Range's.
prange will also have bitmasks, so it will need to use get_bitmask_from_range.
gcc/ChangeLog:
* value-range.cc (get_bitmask_from_range): Move out of irange class.
(irange::get_bitmask): Call function instead of internal method.
* value-range.h (class irange): Remove get_bitmask_from_range.
In preparation for prange, make get_legacy_range take a generic
vrange, not just an irange.
gcc/ChangeLog:
* value-range.cc (get_legacy_range): Make static and add another
version of get_legacy_range that takes a vrange.
* value-range.h (class irange): Remove unnecessary friendship with
get_legacy_range.
(get_legacy_range): Accept a vrange.
We have a sanity check in the irange storage code to make sure that
reading back a cache entry we have just written to yields exactly the
same range. There's no need to do this only for integers. This patch
moves the code to a more generic place.
However, doing so tickles a latent bug in the frange code where a
range is being pessimized from [0.0, 1.0] to [-0.0, 1.0]. Exclude
checking frange's until this bug is fixed.
gcc/ChangeLog:
* value-range-storage.cc (irange_storage::set_irange): Move
verification code from here...
(vrange_storage::set_vrange): ...to here.
Make range_includes_zero_p take an argument instead of a pointer for
consistency in the range-op code.
gcc/ChangeLog:
* gimple-range-op.cc (cfn_clz::fold_range): Change
range_includes_zero_p argument to a reference.
(cfn_ctz::fold_range): Same.
* range-op.cc (operator_plus::lhs_op1_relation): Same.
* value-range.h (range_includes_zero_p): Same.
Conditional operators are always boolean, regardless of their
operands. Getting the type wrong is not currently a problem, but will
be when prange's can no longer store an integer.
gcc/ChangeLog:
* vr-values.cc (simplify_using_ranges::fold_cond_with_ops): Remove
type from range_true and range_false.
Now that we have a vrange storage class to save ranges in long-term
memory, there is no need for GTY markers for any of the vrange
classes, since they should never live in GC.
gcc/ChangeLog:
* value-range-storage.h: Remove friends.
* value-range.cc (gt_ggc_mx): Remove.
(gt_pch_nx): Remove.
* value-range.h (class vrange): Remove GTY markers.
(class irange): Same.
(class int_range): Same.
(class frange): Same.
(gt_ggc_mx): Remove.
(gt_pch_nx): Remove.
Any range can theoretically have a bitmask of set bits. This patch
moves the bitmask accessors to the base class. This cleans up some
users in IPA*, and will provide a cleaner interface when prange is in
place.
gcc/ChangeLog:
* ipa-cp.cc (propagate_bits_across_jump_function): Access bitmask
through base class.
(ipcp_store_vr_results): Same.
* ipa-prop.cc (ipa_compute_jump_functions_for_edge): Same.
(ipcp_get_parm_bits): Same.
(ipcp_update_vr): Same.
* range-op-mixed.h (update_known_bitmask): Change argument to vrange.
* range-op.cc (update_known_bitmask): Same.
* value-range.cc (vrange::update_bitmask): New.
(irange::set_nonzero_bits): Move to vrange class.
(irange::get_nonzero_bits): Same.
* value-range.h (class vrange): Add update_bitmask, get_bitmask,
get_nonzero_bits, and set_nonzero_bits.
(class irange): Make bitmask methods virtual overrides.
(class Value_Range): Add get_bitmask and update_bitmask.
This patch adds vrange::lbound() and vrange::ubound() that return
trees. These can be used in generic code that is type agnostic, and
avoids special casing for pointers and integers in places where we
handle both. It also cleans up a wart in the Value_Range class.
gcc/ChangeLog:
* tree-ssa-loop-niter.cc (refine_value_range_using_guard): Convert
bound to wide_int.
* value-range.cc (Value_Range::lower_bound): Remove.
(Value_Range::upper_bound): Remove.
(unsupported_range::lbound): New.
(unsupported_range::ubound): New.
(frange::lbound): New.
(frange::ubound): New.
(irange::lbound): New.
(irange::ubound): New.
* value-range.h (class vrange): Add lbound() and ubound().
(class irange): Same.
(class frange): Same.
(class unsupported_range): Same.
(class Value_Range): Rename lower_bound and upper_bound to lbound
and ubound respectively.
Fix some Value_Range's that we know ahead of time will be only
integers. This avoids using the polymorphic Value_Range unnecessarily
gcc/ChangeLog:
* gimple-ssa-warn-access.cc (check_nul_terminated_array): Make Value_Range an int_range.
(memmodel_to_uhwi): Same
* tree-ssa-loop-niter.cc (refine_value_range_using_guard): Same.
(determine_value_range): Same.
(infer_loop_bounds_from_signedness): Same.
(scev_var_range_cant_overflow): Same.
Richi mentioned in PR113476 that it would be cleaner to move the
destructor from int_range to the base class. Although this isn't
strictly necessary, as there are no users, it is good to future proof
things, and the overall impact is miniscule.
gcc/ChangeLog:
* value-range.h (vrange::~vrange): New.
(int_range::~int_range): Make final override.
Patch from Björn Schäpers <bjoern@hazardy.de>.
* configure.ac: Checked for tlhelp32.h
* pecoff.c: Include <tlhelp32.h> if available.
(backtrace_initialize): Use tlhelp32 api for a snapshot to
detect loaded modules.
(coff_add): New argument for the module handle of the file,
to get the base address.
* configure, config.h.in: Regenerate.
FreeBSD 7 has been end of life for years and current GCC most likely
would not build there anymore anyways.
gcc:
PR target/69374
PR target/112959
* doc/install.texi (Specific) <*-*-freebsd*>: Remove references to
FreeBSD 7 and older.
So when both source operand and dest operand require avx512 MASK_REGS, RA
can allocate MASK_REGS register instead of GPR to avoid reload it from
GPR to MASK_REGS.
gcc/ChangeLog:
* config/i386/i386.md: (zero_extendsidi2): Adjust
alternative *k to ?k.
(zero_extend<mode>di2): Ditto.
(*zero_extend<mode>si2): Ditto.
(*zero_extendqihi2): Ditto.
Some tests fail on ppc and ppc64 when testing a compiler [with options
for] for a CPU [emulator] that doesn't support the sqrt insn.
The gcc.dg/cdce3.c is one in which the expected shrink-wrap
optimization only takes place when the target CPU supports a sqrt
insn.
The gcc.target/powerpc/pr46728-1[0-4].c tests use -mpowerpc-gpopt and
call sqrt(), which involves the sqrt insn that the target CPU under
test may not support.
Require a sqrt_insn effective target for all the affected tests.
for gcc/testsuite/ChangeLog
* gcc.dg/cdce3.c: Require sqrt_insn effective target.
* gcc.target/powerpc/pr46728-10.c: Likewise. Drop darwin
explicit skipping.
* gcc.target/powerpc/pr46728-11.c: Likewise. Likewise.
* gcc.target/powerpc/pr46728-13.c: Likewise. Likewise.
* gcc.target/powerpc/pr46728-14.c: Likewise. Likewise.
