Here a stale TYPE_DEPENDENT_P/_P_VALID value for f's function type
after replacing the type's DEFERRED_NOEXCEPT with the parsed dependent
noexcept-spec causes us to try to instantiate g's noexcept-spec ahead
of time (since it in turn appears non-dependent), leading to an ICE.
This patch fixes this by clearing TYPE_DEPENDENT_P_VALID in
fixup_deferred_exception_variants appropriately (as in
build_cp_fntype_variant).
That turns out to fix the testcase for C++17 but not for C++11/14,
because it's not until C++17 that a noexcept-spec is part of (and
therefore affects dependence of) the function type. Since dependence of
NOEXCEPT_EXPR is defined in terms of instantiation dependence, the most
appropriate fix for earlier dialects seems to be to make instantiation
dependence consider dependence of a noexcept-spec.
PR c++/104079
gcc/cp/ChangeLog:
* pt.cc (value_dependent_noexcept_spec_p): New predicate split
out from ...
(dependent_type_p_r): ... here.
(instantiation_dependent_r): Use value_dependent_noexcept_spec_p
to consider dependence of a noexcept-spec before C++17.
* tree.cc (fixup_deferred_exception_variants): Clear
TYPE_DEPENDENT_P_VALID.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept74.C: New test.
* g++.dg/cpp0x/noexcept74a.C: New test.
This patch fixes various issues with how -fanalyzer handles "realloc"
seen when debugging PR analyzer/104369.
Previously it wasn't correctly copying over the contents of the old
buffer for the success-with-move case, leading to false
-Wanalyzer-use-of-uninitialized-value diagnostics.
I also noticed that -fanalyzer failed to properly handle "realloc" for
cases where the ptr's region had unknown dynamic extents, and an ICE
for the case where a tainted value is used as a realloc size argument.
This patch fixes these issues, including the false uninit diagnostics
seen in PR analyzer/104369.
gcc/analyzer/ChangeLog:
PR analyzer/104369
* engine.cc (exploded_graph::process_node): Use the node for any
diagnostics, avoiding ICE if a bifurcation update adds a
saved_diagnostic, such as for a tainted realloc size.
* region-model-impl-calls.cc
(region_model::impl_call_realloc::success_no_move::update_model):
Require the old pointer to be non-NULL to be able successfully
grow in place. Use model->deref_rvalue rather than maybe_get_region
to support the old pointer being symbolic.
(region_model::impl_call_realloc::success_with_move::update_model):
Likewise. Add a constraint that the new pointer != the old pointer.
Use a sized_region when setting the value of the new region.
Handle the case where we don't know the dynamic size of the old
region by marking the new region as unknown.
* sm-taint.cc (tainted_allocation_size::tainted_allocation_size):
Update assertion to also allow for MEMSPACE_UNKNOWN.
(tainted_allocation_size::emit): Likewise.
(region_model::check_dynamic_size_for_taint): Likewise.
gcc/testsuite/ChangeLog:
PR analyzer/104369
* gcc.dg/analyzer/pr104369-1.c: New test.
* gcc.dg/analyzer/pr104369-2.c: New test.
* gcc.dg/analyzer/realloc-3.c: New test.
* gcc.dg/analyzer/realloc-4.c: New test.
* gcc.dg/analyzer/taint-realloc.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
It turned out that the analyzer wasn't treating calloc regions
as zero-filled, due to binding_cluster::fill_region getting an
unknown value for the byte_size_size_sval, and thus
get_or_create_repeated_svalue returning an unknown_svalue, which
was then used to fill the region.
Fixed thusly.
gcc/analyzer/ChangeLog:
* region-model-impl-calls.cc (region_model::impl_call_calloc): Use
a sized_region when calling zero_fill_region.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/calloc-1.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
%ecx can't be used for both DRAP register and eh_return. Adjust find_drap_reg
to choose %edi for functions that uses __builtin_eh_return to avoid the assert
in ix86_expand_epilogue that enforces this rule.
2022-02-03 Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog:
PR target/104362
* config/i386/i386.cc (find_drap_reg): For 32bit targets
return DI_REG if function uses __builtin_eh_return.
gcc/testsuite/ChangeLog:
PR target/104362
* gcc.target/i386/pr104362.c: New test.
gcc/fortran/ChangeLog:
PR fortran/104311
* check.cc (gfc_calculate_transfer_sizes): Checks for case when
storage size of SOURCE is greater than zero while the storage size
of MOLD is zero and MOLD is an array shall not depend on SIZE.
gcc/testsuite/ChangeLog:
PR fortran/104311
* gfortran.dg/transfer_simplify_15.f90: New test.
In my case:
$ rm ./stmp-fixinc ; time make -j16
takes 17 seconds, where I can reduce it easily with the suggested
change. Then I get to 11.2 seconds.
The scripts searches ~2500 folders in my case with total 20K header
files.
fixincludes/ChangeLog:
* fixinc.in: Use mkdir -p rather that a loop.
The -m[no-]fold-gimple flag was really intended primarily for internal
testing while implementing GIMPLE folding for rs6000 vector built-in
functions. It ended up leaking into other places, causing problems such
as PR103686 identifies. Let's remove it.
There are a number of tests in the testsuite that require adjustment.
Some specify -mfold-gimple directly, which is the default, so that is
handled by removing the option. Others unnecessarily specify
-mno-fold-gimple, as the tests work fine without this. Again that is
handled by removing the option. There are a couple of extra variants of
tests specifically for -mno-fold-gimple; for those, we can just remove the
whole test.
gcc.target/powerpc/builtins-1.c was more problematic. It was written in
such a way as to be extremely fragile. For this one, I rewrote the whole
test in a different style, using individual functions to test each
built-in function. These same tests are also largely covered by
builtins-1-be-folded.c and builtins-1-le-folded.c, so I chose to
explicitly make this test -mbig for simplicity, and use -O2 for clean code
generation. I made some slight modifications to the expected instruction
counts as a result, and tested on both 32- and 64-bit.
2022-02-02 Bill Schmidt <wschmidt@linux.ibm.com>
gcc/
PR target/103686
* config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_builtin): Remove
test for !rs6000_fold_gimple.
* config/rs6000/rs6000.cc (rs6000_option_override_internal): Likewise.
* config/rs6000/rs6000.opt (mfold-gimple): Remove.
gcc/testsuite/
PR target/103686
* gcc.target/powerpc/builtins-1-be-folded.c: Remove -mfold-gimple
option.
* gcc.target/powerpc/builtins-1-le-folded.c: Likewise.
* gcc.target/powerpc/builtins-1.c: Rewrite to use small functions and
restrict to -O2 -mbig for predictability. Adjust instruction counts.
* gcc.target/powerpc/builtins-5.c: Remove -mno-fold-gimple option.
* gcc.target/powerpc/p8-vec-xl-xst.c: Likewise.
* gcc.target/powerpc/pr83926.c: Likewise.
* gcc.target/powerpc/pr86731-nogimplefold-longlong.c: Delete.
* gcc.target/powerpc/pr86731-nogimplefold.c: Delete.
* gcc.target/powerpc/swaps-p8-17.c: Remove -mno-fold-gimple option.
These built-ins were misimplemented as always having big-endian semantics.
2022-01-18 Bill Schmidt <wschmidt@linux.ibm.com>
gcc/
PR target/95082
* config/rs6000/rs6000-builtin.cc (rs6000_expand_builtin): Handle
endianness for vclzlsbb and vctzlsbb.
* config/rs6000/rs6000-builtins.def (VCLZLSBB_V16QI): Change
default pattern and indicate a different pattern will be used for
big endian.
(VCLZLSBB_V4SI): Likewise.
(VCLZLSBB_V8HI): Likewise.
(VCTZLSBB_V16QI): Likewise.
(VCTZLSBB_V4SI): Likewise.
(VCTZLSBB_V8HI): Likewise.
gcc/testsuite/
PR target/95082
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-0.c: Restrict to -mbig.
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-1.c: Likewise.
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-3.c: New.
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-4.c: New.
* gcc.target/powerpc/vsu/vec-cnttz-lsbb-0.c: Restrict to -mbig.
* gcc.target/powerpc/vsu/vec-cnttz-lsbb-1.c: Likewise.
* gcc.target/powerpc/vsu/vec-cnttz-lsbb-3.c: New.
* gcc.target/powerpc/vsu/vec-cnttz-lsbb-4.c: New.
Continuing with the refactoring effort, this patch moves as much of the
target-specific built-in support code into a new file, rs6000-builtin.cc.
However, we can't easily move the overloading support code out of
rs6000-c.cc, because the build machinery understands that as a special file
to be included with the C and C++ front ends.
This patch is just a straightforward move, with one exception. I found
that the builtin_mode_to_type[] array is no longer used, so I also removed
all code having to do with it.
The code in rs6000-builtin.cc is organized in related sections:
- General support functions
- Initialization support
- GIMPLE folding support
- Expansion support
Overloading support remains in rs6000-c.cc.
2022-02-03 Bill Schmidt <wschmidt@linux.ibm.com>
gcc/
* config.gcc (powerpc*-*-*): Add rs6000-builtin.o to extra_objs.
* config/rs6000/rs6000-builtin.cc: New file, containing code moved
from other files.
* config/rs6000/rs6000-call.cc (cpu_is_info): Move to
rs6000-builtin.cc.
(cpu_supports_info): Likewise.
(rs6000_type_string): Likewise.
(altivec_expand_predicate_builtin): Likewise.
(rs6000_htm_spr_icode): Likewise.
(altivec_expand_vec_init_builtin): Likewise.
(get_element_number): Likewise.
(altivec_expand_vec_set_builtin): Likewise.
(altivec_expand_vec_ext_builtin): Likewise.
(rs6000_invalid_builtin): Likewise.
(rs6000_fold_builtin): Likewise.
(fold_build_vec_cmp): Likewise.
(fold_compare_helper): Likewise.
(map_to_integral_tree_type): Likewise.
(fold_mergehl_helper): Likewise.
(fold_mergeeo_helper): Likewise.
(rs6000_builtin_valid_without_lhs): Likewise.
(rs6000_builtin_is_supported): Likewise.
(rs6000_gimple_fold_mma_builtin): Likewise.
(rs6000_gimple_fold_builtin): Likewise.
(rs6000_expand_ldst_mask): Likewise.
(cpu_expand_builtin): Likewise.
(elemrev_icode): Likewise.
(ldv_expand_builtin): Likewise.
(lxvrse_expand_builtin): Likewise.
(lxvrze_expand_builtin): Likewise.
(stv_expand_builtin): Likewise.
(mma_expand_builtin): Likewise.
(htm_spr_num): Likewise.
(htm_expand_builtin): Likewise.
(rs6000_expand_builtin): Likewise.
(rs6000_vector_type): Likewise.
(rs6000_init_builtins): Likewise. Remove initialization of
builtin_mode_to_type entries.
(rs6000_builtin_decl): Move to rs6000-builtin.cc.
* config/rs6000/rs6000.cc (rs6000_builtin_mask_for_load): New
external declaration.
(rs6000_builtin_md_vectorized_function): Likewise.
(rs6000_builtin_reciprocal): Likewise.
(altivec_builtin_mask_for_load): Move to rs6000-builtin.cc.
(rs6000_builtin_types): Likewise.
(builtin_mode_to_type): Remove.
(rs6000_builtin_mask_for_load): Move to rs6000-builtin.cc. Remove
static qualifier.
(rs6000_builtin_md_vectorized_function): Likewise.
(rs6000_builtin_reciprocal): Likewise.
* config/rs6000/rs6000.h (builtin_mode_to_type): Remove.
* config/rs6000/t-rs6000 (rs6000-builtin.o): New target.
The following avoids NRV from massaging DECL_ABSTRACT_ORIGIN after
variable creation since NRV runs _after_ the function was inlined and thus
affects the inlined variables copy indirectly. We may adjust the abstract
origin of a variable only at the point we create it, not further along the
path since otherwise the (new) invariant that the abstract origin is always
the ultimate origin cannot be maintained.
The intent of what NRV does is OK I guess and it may improve the debug
experience. But I also notice we do
SET_DECL_VALUE_EXPR (found, result);
DECL_HAS_VALUE_EXPR_P (found) = 1;
the code is there since the merge from tree-ssa which added tree-nrv.c.
Jakub added the DECL_VALUE_EXPR in g:938650d8fddb878f623e315f0b7fd94b217efa96
and Jason added the abstract origin setting conditional in g:7716876bbd3a
The follwoing takes the radical approach and remove the attempt
to "optimize" the debug info.
The gdb testsuites show no regressions.
2022-02-03 Richard Biener <rguenther@suse.de>
PR debug/104337
* tree-nrv.cc (pass_nrv::execute): Remove tieing result and found
together via DECL_ABSTRACT_ORIGIN.
* gcc.dg/debug/pr104337.c: New testcase.
The fur_list constructor for two ranges is leaving [1] in an undefined
state. The reason we haven't noticed is because after all the
shuffling in the last cycle there are no remaining users of it
(similarly for fur_list(unsigned, irange *)).
Since it's very late in the cycle, I would prefer to fix this, rather
than removing unused constructors altogether. Besides, we have uses
of them queued up for the next release.
gcc/ChangeLog:
* gimple-range-fold.cc (fur_list::fur_list): Set m_local[1] correctly.
On Thu, Jan 20, 2022 at 11:27:20AM +0000, Richard Earnshaw via Gcc-patches wrote:
> gcc/ChangeLog:
>
> * config/arm/arm.opt (mfix-cortex-a57-aes-1742098): New command-line
> option.
> (mfix-cortex-a72-aes-1655431): New option alias.
> --- a/gcc/config/arm/arm.opt
> +++ b/gcc/config/arm/arm.opt
> @@ -272,6 +272,16 @@ mfix-cmse-cve-2021-35465
> Target Var(fix_vlldm) Init(2)
> Mitigate issues with VLLDM on some M-profile devices (CVE-2021-35465).
>
> +mfix-cortex-a57-aes-1742098
> +Target Var(fix_aes_erratum_1742098) Init(2) Save
> +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72.
> +Arm erratum #1742098
> +
> +mfix-cortex-a72-aes-1655431
> +Target Alias(mfix-cortex-a57-aes-1742098)
> +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72.
> +Arm erratum #1655431
> +
> munaligned-access
> Target Var(unaligned_access) Init(2) Save
> Enable unaligned word and halfword accesses to packed data.
This breaks:
Running /usr/src/gcc/gcc/testsuite/gcc.misc-tests/help.exp ...
FAIL: compiler driver --help=target option(s): "^ +-.*[^:.]$" absent from output: " -mfix-cortex-a57-aes-1742098 Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72. Arm erratum #1742098"
help.exp with help of lib/options.exp tests whether all non-empty descriptions of
options are terminated with . or :.
2022-02-03 Jakub Jelinek <jakub@redhat.com>
* config/arm/arm.opt (mfix-cortex-a57-aes-1742098,
mfix-cortex-a72-aes-1655431): Ensure description ends with full stop.
The hardware instruction does not trap on divide by zero there.
gcc/testsuite
PR tree-optimization/104356
* gnat.dg/div_zero.adb: Add dg-skip-if directive for PowerPC.
At some point we started generating the intended code for
aarch64/sve/struct_vect_25.c. This patch removes the xfails
and the scan-assembler-times that replaced the xfailed forms.
gcc/testsuite/
* gcc.target/aarch64/sve/struct_vect_25.c: Remove XFAILs.
After the fix for PR102659, the vectoriser can no longer group
conditional accesses of the form:
for (int i = 0; i < n; ++i)
if (...)
...a[i * 2] + a[i * 2 + 1]...;
on LP64 targets. It has to treat them as two independent
gathers instead.
This was causing failures in the sve mask_struct*.c tests.
The tests weren't really testing that int iterators could
be used, so this patch switches to pointer-sized iterators
instead.
gcc/testsuite/
* gcc.target/aarch64/sve/mask_struct_load_1.c: Use intptr_t
iterators instead of int iterators.
* gcc.target/aarch64/sve/mask_struct_load_2.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_3.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_4.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_5.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_6.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_7.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_8.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_1.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_2.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_3.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_4.c: Likewise.
The Advanced SIMD movmisalign patterns didn't handle 16-bit
FP modes, which meant that the vector loop for:
void
test (_Float16 *data)
{
_Pragma ("omp simd")
for (int i = 0; i < 8; ++i)
data[i] = 1.0;
}
would be versioned for alignment.
This was causing some new failures in aarch64/sve/single_5.c:
FAIL: gcc.target/aarch64/sve/single_5.c scan-assembler-not \\tb
FAIL: gcc.target/aarch64/sve/single_5.c scan-assembler-not \\tcmp
FAIL: gcc.target/aarch64/sve/single_5.c scan-assembler-times \\tstr\\tq[0-9]+, 10
but I didn't look into what changed from earlier releases.
Adding the missing modes removes some existing xfails.
gcc/
* config/aarch64/aarch64-simd.md (movmisalign<mode>): Extend from
VALL to VALL_F16.
gcc/testsuite/
* gcc.target/aarch64/sve/single_5.c: Remove some XFAILs.
The VALL_F16MOV iterator now has the same modes as VALL_F16,
in the same order. This patch removes the former in favour
of the latter.
This doesn't fix a bug as such, but it's ultra-safe (no change in
object code) and it saves a follow-up patch from having to make
a false choice between the iterators.
gcc/
* config/aarch64/iterators.md (VALL_F16MOV): Delete.
* config/aarch64/aarch64-simd.md (mov<mode>): Use VALL_F16 instead
of VALL_F16MOV.
Following on from GCC 11 patch g:f31ddad8ac8, this one gives clean
guality.exp test results for aarch64-linux-gnu with modern gdb
(this time gdb 11.2).
The justification is the same as previously:
------
For people using older gdbs, it will trade one set of noisy results for
another set. I still think it's better to have the xfails based on
one “clean” and “modern” run rather than have FAILs and XPASSes for
all runs.
It's hard to tell which of these results are aarch64-specific and
which aren't. If other target maintainers want to do something similar,
and are prepared to assume the same gdb version, then it should become
clearer over time which ones are target-specific and which aren't.
There are no new skips here, so changes in test results will still
show up as XPASSes.
I've not analysed the failures or filed PRs for them. In some
ways the guality directory itself seems like the best place to
start looking for xfails, if someone's interested in working
in this area.
------
gcc/testsuite/
* gcc.dg/guality/ipa-sra-1.c: Update aarch64*-*-* xfails.
* gcc.dg/guality/pr54519-1.c: Likewise.
* gcc.dg/guality/pr54519-3.c: Likewise.
The wide-int.h templates expect that when an int/long etc. operand is used
it will be sign-extended based on the types precision.
wi_fold_in_parts passes 3 such non-zero constants to wi::lt_p, wi::gt_p
and wi::eq_p - 1, 3 and 4, which means it was doing weird things if either
some of 1, 3 or 4 weren't representable in type, or if type was unsigned 3 bit
type 4 should be written as -4.
The following patch promotes the subtraction operands to widest_int and
uses that as the type for ?h_range variables and compares them as such.
We don't need the overflow handling because there is never an overflow.
2022-02-02 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/104334
* range-op.cc (range_operator::wi_fold_in_parts): Change lh_range
and rh_range type to widest_int and subtract in widest_int. Remove
ov_rh, ov_lh and sign vars, always perform comparisons as signed
and use >, < and == operators for it.
* g++.dg/opt/pr104334.C: New test.
The testcase shows some cases that weren't verified and we ICE on
invalid because of that.
One problem is that unlike before, we weren't checking if some expression
is EXPR_VARIABLE with non-NULL symtree in the case where there was
a conversion around it.
The other two issues is that we check that in an IF ->block is non-NULL
and then immediately dereference ->block->next->op, but on invalid
code with no statements in the then clause ->block->next might be NULL.
2022-02-02 Jakub Jelinek <jakub@redhat.com>
PR fortran/104328
* openmp.cc (is_scalar_intrinsic_expr): If must_be_var && conv_ok
and expr is conversion, verify it is a conversion from EXPR_VARIABLE
with non-NULL symtree. Check ->block->next before dereferencing it.
* gfortran.dg/gomp/atomic-27.f90: New test.
The patch for PR55227 changed the minimal init-list handling in
cp_complete_array_type to a call to reshape_init, which broke on the
dependent initializer. It occurred to me that trying to deduce the array
size from a dependent init-list is wrong in general, so let's just not. I
also limited the reshape_init call to the case of a char array, as before
the patch for 55227; that's the only case where we want to strip a level of
braces from an array.
PR c++/104302
gcc/cp/ChangeLog:
* decl.cc (maybe_deduce_size_from_array_init): Give up
on type-dependent init.
(cp_complete_array_type): Only call reshape_init for character
array.
gcc/testsuite/ChangeLog:
* g++.dg/template/array35.C: New test.
* g++.dg/template/array36.C: New test.
2022-02-02 Segher Boessenkool <segher@kernel.crashing.org>
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_powerpc_altivec_ok):
Return 0 if the target is not Power. Restructure and add some comments.
If _GLIBCXX_THROW_OR_ABORT expands to just __builtin_abort() then the
bool variable used in the filesystem_error constructor is unused. Mark
it as maybe_unused to there's no warning for -fno-exceptions builds.
libstdc++-v3/ChangeLog:
* src/c++17/fs_dir.cc (fs::recursive_directory_iterator::pop):
Add [[maybe_unused]] attribute.
* src/filesystem/dir.cc (fs::recursive_directory_iterator::pop):
Likewise.
These tests instantiate std::multiset and std::set with a type that has
no operator< so they should use a custom comparison function.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/multiset/operators/cmp_c++20.cc: Use
custom comparison function for multiset.
* testsuite/23_containers/set/operators/cmp_c++20.cc: Use custom
comparison function for set.
The C++98-style concept check for output iterators causes a link
failure on mingw-w64, because the __val() member function isn't defined.
Change it to use a function pointer instead. That pointer is never set
to anything meaningful, but it doesn't matter as the __constraints()
function only has to be instantiated, it's never called.
We could refactor all of these to use unevaluated contexts (e.g. sizeof
of __decltype) so that we only check the expressions are well-formed,
without any codegen at all. Any improvements to these are very low
priority though.
libstdc++-v3/ChangeLog:
* include/bits/boost_concept_check.h (_OutputIteratorConcept):
Change member function to data member of function pointer type.
When one uses something like: -Wl,-plugin-opt=debug,
we end up with lto1 WPA invocation that has 'debug'
on command line. We interpret that as input filename.
The patch moves resolution checking later so that we end up with
a reasonable error message:
lto1: fatal error: open debug failed: No such file or directory
compilation terminated.
PR lto/104333
gcc/lto/ChangeLog:
* lto-common.cc (read_cgraph_and_symbols): Move resolution
checking for number of files later and report a reasonable
error message.
* lto-object.cc (lto_obj_file_open): Make error fatal.
When moving the -fanalyzer tests for -ftrivial-auto-var-init to the
"torture" subdirectory of gcc.dg/analyzer I noticed that -fanalyzer
wasn't always properly checking for initialization of return values.
The issue was that some "return" handling was using
region_model::copy_region to copy to the RESULT_DECL, and copy_region
wasn't checking for poisoned svalues.
This patch eliminates region_model::copy_region in favor of simply
doing a get_ravlue/set_value pair, fixing the issue.
gcc/analyzer/ChangeLog:
* region-model.cc (region_model::on_return): Replace usage of
copy_region with get_rvalue/set_value pair.
(region_model::pop_frame): Likewise.
(selftest::test_compound_assignment): Likewise.
* region-model.h (region_model::copy_region): Delete decl.
* region.cc (region_model::copy_region): Delete.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/torture/ubsan-1.c: Add missing return stmts.
* gcc.dg/analyzer/uninit-trivial-auto-var-init-pattern.c: Move
to...
* gcc.dg/analyzer/torture/uninit-trivial-auto-var-init-pattern.c:
...here.
* gcc.dg/analyzer/uninit-trivial-auto-var-init-uninitialized.c:
Move to...
* gcc.dg/analyzer/torture/uninit-trivial-auto-var-init-uninitialized.c:
...here.
* gcc.dg/analyzer/uninit-trivial-auto-var-init-zero.c: Move to...
* gcc.dg/analyzer/torture/uninit-trivial-auto-var-init-zero.c: ...here.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
GCC 12 has gained -Wanalyzer-use-of-uninitialized-value, and I'm
seeing various false positives from it due to region_model::get_lvalue
not properly handling BIT_FIELD_REF, and falling back to
using an UNKNOWN_REGION for them.
This patch fixes these false positives by implementing a new
bit_range_region region subclass for handling BIT_FIELD_REF.
gcc/analyzer/ChangeLog:
* analyzer.h (class bit_range_region): New forward decl.
* region-model-manager.cc (region_model_manager::get_bit_range):
New.
(region_model_manager::log_stats): Handle m_bit_range_regions.
* region-model.cc (region_model::get_lvalue_1): Handle
BIT_FIELD_REF.
* region-model.h (region_model_manager::get_bit_range): New decl.
(region_model_manager::m_bit_range_regions): New field.
* region.cc (region::get_base_region): Handle RK_BIT_RANGE.
(region::base_region_p): Likewise.
(region::calc_offset): Likewise.
(bit_range_region::dump_to_pp): New.
(bit_range_region::get_byte_size): New.
(bit_range_region::get_bit_size): New.
(bit_range_region::get_byte_size_sval): New.
(bit_range_region::get_relative_concrete_offset): New.
* region.h (enum region_kind): Add RK_BIT_RANGE.
(region::dyn_cast_bit_range_region): New vfunc.
(class bit_range_region): New.
(is_a_helper <const bit_range_region *>::test): New.
(default_hash_traits<bit_range_region::key_t>): New.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/torture/uninit-bit-field-ref.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
GCC 12 has gained two features for dealing with uninitialized variables:
(a) a new -Wanalyzer-use-of-uninitialized-value warning within -fanalyzer
for interprocedural path-sensitive detection of ununit uses, and
(b) a new -ftrivial-auto-var-init option for mitigating some uses of
uninit variables
It turns out that using (b) was thwarting (a), as it led to -fanalyzer
seeing calls to IFN_DEFERRED_INIT, which -fanalyzer wasn't
special-casing, thus treating it as initializing the variables in
question, and thus silencing -Wanalyzer-use-of-uninitialized-value on
them.
invoke.texi says:
"GCC still considers an automatic variable that doesn't have an explicit
initializer as uninitialized, @option{-Wuninitialized} will still report
warning messages on such automatic variables."
and thus -Wanalyzer-use-of-uninitialized-value ought to as well.
This patch adds special-case handling to -fanalyzer for
IFN_DEFERRED_INIT, so that -fanalyzer will warn on uninit uses of
variables that are mitigated by -ftrivial-auto-var-init.
gcc/analyzer/ChangeLog:
PR analyzer/104270
* region-model.cc (region_model::on_call_pre): Handle
IFN_DEFERRED_INIT.
gcc/testsuite/ChangeLog:
PR analyzer/104270
* gcc.dg/analyzer/uninit-trivial-auto-var-init-pattern.c: New
test.
* gcc.dg/analyzer/uninit-trivial-auto-var-init-uninitialized.c:
New test.
* gcc.dg/analyzer/uninit-trivial-auto-var-init-zero.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
The detection of pthread support fails on OpenRISC unless _REENTRANT
is defined. Added the CPP_SPEC definition to correct this.
gcc/ChangeLog:
PR target/94372
* config/or1k/linux.h (CPP_SPEC): Define.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
After the first patch in the series this updates the optabs to expect the
canonical sequence.
gcc/ChangeLog:
PR tree-optimization/102819
PR tree-optimization/103169
* config/arm/vec-common.md (cml<fcmac1><conj_op><mode>4): Use
canonical order.
After the first patch in the series this updates the optabs to expect the
canonical sequence.
gcc/ChangeLog:
PR tree-optimization/102819
PR tree-optimization/103169
* config/aarch64/aarch64-simd.md (cml<fcmac1><conj_op><mode>4): Use
canonical order.
* config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4): Likewise.
This patch boosts the analysis for complex mul,fma and fms in order to ensure
that it doesn't create an incorrect output.
Essentially it adds an extra verification to check that the two nodes it's going
to combine do the same operations on compatible values. The reason it needs to
do this is that if one computation differs from the other then with the current
implementation we have no way to deal with it since we have to remove the
permute.
When we can keep the permute around we can probably handle these by unrolling.
While implementing this since I have to do the traversal anyway I took advantage
of it by simplifying the code a bit. Previously we would determine whether
something is a conjugate and then try to figure out which conjugate it is and
then try to see if the permutes match what we expect.
Now the code that does the traversal will detect this in one go and return to us
whether the operation is something that can be combined and whether a conjugate
is present.
Secondly because it does this I can now simplify the checking code itself to
essentially just try to apply fixed patterns to each operation.
The patterns represent the order operations should appear in. For instance a
complex MUL operation combines :
Left 1 + Right 1
Left 2 + Right 2
with a permute on the nodes consisting of:
{ Even, Even } + { Odd, Odd }
{ Even, Odd } + { Odd, Even }
By abstracting over these patterns the checking code becomes quite simple.
As part of this I was checking the order of the operands which was left in
"slp" order. as in, the same order they showed up in during SLP, which means
that the accumulator is first. However it looks like I didn't document this
and the x86 optab was implemented assuming the same order as FMA, i.e. that
the accumulator is last.
I have this changed the order to match that of FMA and FMS which corrects the
x86 codegen and will update the Arm targets. This has now also been
documented.
gcc/ChangeLog:
PR tree-optimization/102819
PR tree-optimization/103169
* doc/md.texi: Update docs for cfms, cfma.
* tree-data-ref.h (same_data_refs): Accept optional offset.
* tree-vect-slp-patterns.cc (is_linear_load_p): Fix issue with repeating
patterns.
(vect_normalize_conj_loc): Remove.
(is_eq_or_top): Change to take two nodes.
(enum _conj_status, compatible_complex_nodes_p,
vect_validate_multiplication): New.
(class complex_add_pattern, complex_add_pattern::matches,
complex_add_pattern::recognize, class complex_mul_pattern,
complex_mul_pattern::recognize, class complex_fms_pattern,
complex_fms_pattern::recognize, class complex_operations_pattern,
complex_operations_pattern::recognize, addsub_pattern::recognize): Pass
new cache.
(complex_fms_pattern::matches, complex_mul_pattern::matches): Pass new
cache and use new validation code.
* tree-vect-slp.cc (vect_match_slp_patterns_2, vect_match_slp_patterns,
vect_analyze_slp): Pass along cache.
(compatible_calls_p): Expose.
* tree-vectorizer.h (compatible_calls_p, slp_node_hash,
slp_compat_nodes_map_t): New.
(class vect_pattern): Update signatures include new cache.
gcc/testsuite/ChangeLog:
PR tree-optimization/102819
PR tree-optimization/103169
* g++.dg/vect/pr99149.cc: xfail for now.
* gcc.dg/vect/complex/pr102819-1.c: New test.
* gcc.dg/vect/complex/pr102819-2.c: New test.
* gcc.dg/vect/complex/pr102819-3.c: New test.
* gcc.dg/vect/complex/pr102819-4.c: New test.
* gcc.dg/vect/complex/pr102819-5.c: New test.
* gcc.dg/vect/complex/pr102819-6.c: New test.
* gcc.dg/vect/complex/pr102819-7.c: New test.
* gcc.dg/vect/complex/pr102819-8.c: New test.
* gcc.dg/vect/complex/pr102819-9.c: New test.
* gcc.dg/vect/complex/pr103169.c: New test.
