gcc/testsuite/ChangeLog:
PR analyzer/109016
* gcc.dg/analyzer/omp-parallel-for-1.c: New test.
* gcc.dg/analyzer/omp-parallel-for-get-min.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Previously, the analyzer lacked a known_function implementation of
sprintf, and thus would handle calls to sprintf with the "anything could
happen" fallback.
Whilst working on PR analyzer/107565 I noticed that this was preventing
a lot of genuine memory leaks from being reported for Doom; fixing
thusly.
Integration testing of the effect of the patch shows a big increase in
true positives due to the case mentioned in Doom, and one new false
positive (in pcre2), which I'm tracking as PR analyzer/109014.
Comparison:
GOOD: 67 -> 123 (+56); 10.91% -> 18.33%
BAD: 547 -> 548 (+1)
where the affected warnings/projects are:
-Wanalyzer-malloc-leak:
GOOD: 0 -> 56 (+56); 0.00% -> 41.48%
BAD: 79
True positives: 0 -> 56 (+56)
(all in Doom)
-Wanalyzer-use-of-uninitialized-value:
GOOD: 0; 0.00%
BAD: 80 -> 81 (+1)
False positives:
pcre2-10.42: 0 -> 1 (+1)
gcc/analyzer/ChangeLog:
* kf.cc (class kf_sprintf): New.
(register_known_functions): Register it.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/doom-d_main-IdentifyVersion.c: New test.
* gcc.dg/analyzer/sprintf-1.c: New test.
* gcc.dg/analyzer/sprintf-concat.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
The async call and future variable initialization may take a while to
complete on uniprocessors, especially if the async call and other
unrelated processes run before context switches back to the main
thread.
Taking steady_begin only then sometimes causes the 11*100ms in the
slow clock, counted from before the async call, to not be enough for
the measured wait to last 1s in the steady clock. I've seen it fall
short of 1s by as little as a third of a tenth of a second in some
cases, but in one surprisingly extreme case the elapsed wait time got
only up to 216.7ms.
Initializing both timestamps next to each other, before the async
call, appears to avoid the problem entirely. I've renamed the
variable moved out of the block so as to avoid name hiding in the
subsequent block, that has another steady_begin variable.
The second wait fails a lot less frequently, but the 2s limit has been
exceeded, so I'm bumping up the max sleep to ~4s, and the tolerance to
3s.
for libstdc++-v3/ChangeLog
* testsuite/30_threads/async/async.cc (test04): Initialize
steady_start, renamed from steady_begin, next to slow_start.
Increase tolerance for final wait.
We're getting regressions after ugprading to GDB 13 in a few of the
libstdc++ pretty-printing tests. It might seem like a GDB regression,
but that update has a new symbol reader, and Tom Tromey says it
exposes a latent problem in the pretty-printer, namely, when a name is
not defined locally in the local translation unit, GDB will look for
it in other units, and if multiple different definitions are
available, there are no guarantees as to which one it will find.
Since libstdc++ contains units in which std::string maps to different
types, in order to ensure the tests get the std::string definition we
expect, we need std::string to be present in the debug information for
the test itself, as we already do in other tests.
for libstdc++-v3/ChangeLog
* testsuite/libstdc++-prettyprinters/80276.cc: Add
std::string to debug info.
* testsuite/libstdc++-prettyprinters/libfundts.cc: Likewise.
Like pthread_create, pthread_join may fail to be statically linked in
absent strong uses, so add to user code strong references to both when
std::thread objects are created.
for libstdc++-v3/ChangeLog
PR libstdc++/104852
PR libstdc++/95989
PR libstdc++/52590
* include/bits/std_thread.h (thread::_M_thread_deps): New
static implicitly-inline member function.
(std::thread template ctor): Pass it to _M_start_thread.
* src/c++11/thread.cc (thread::_M_start_thread): Name depend
parameter, force it live on entry.
check_dangling_stores has some weirdnesses that causes its behavior to
change when the target ABI requires C++ ctors to return this: while
scanning stmts backwards in e.g. the AS ctor on a target that returns
this in ctors, the scan first encounters a copy of this to the SSA
name used to hold the return value. m_ptr_query.get_ref resolves lhs
(the return SSA name) to the rhs (the default SSA name for this), does
not skip it because auto_var_p is false for SSA_NAMEs, and proceeds to
add it to stores, which seems to prevent later attempts to add stores
into *this from succeeding, which disables warnings that should have
triggered.
This is also the case when the backwards search finds unrelated stores
to other fields of *this before it reaches stores that IMHO should be
warned about. The store found first disables checking of other
stores, as if the store appearing later in the code would necessarily
overwrite the store that should be warned about. I've added an
xfailed variant of the existing test (struct An) that triggers this
problem, but I'm not sure how to go about fixing it.
Meanwhile, this patch prevents assignments with SSA_NAMEs in the lhs
from being regarded as stores, which is enough to remove the
undesirable side effect on -Wdangling-pointer of ABI-mandated ctors'
returning this. Another variant of the existing test (struct Al) that
demonstrates the problem regardless of this aspect of the ABI, and
that gets the desired warning with the proposed patch, but not
without.
Curiously, this fix exposes yet another problem in
Wdangling-pointer-5.c: it is the return stmt of the unrelated pointer
p, not the store into possibly-overlapping *vpp2, that caused the
warning to not be issued for the store in *vpp1. I'm not sure whether
we should or should not warn in that case, but this patch adjusts the
test to reflect the behavior change.
for gcc/ChangeLog
* gimple-ssa-warn-access.cc
(pass_waccess::check_dangling_stores): Skip non-stores.
for gcc/testsuite/ChangeLog
* g++.dg/warn/Wdangling-pointer.C (warn_init_ref_member): Add
two new variants, one fixed, one xfailed.
* c-c++-common/Wdangling-pointer-5.c
(nowarn_store_arg_store_arg): Add now-expected warnings.
Back when quotes were added around "+cdecp<N>" in the "coproc must be
a constant immediate" error in arm-builtins.cc, tests for that message
lagged behind. Fixed thusly.
for gcc/testsuite/ChangeLog
* gcc.target/arm/acle/cde-errors.c: Adjust messages for quote
around +cdecp<N>.
* gcc.target/arm/acle/cde-mve-error-2.c: Likewise.
Commit 3a7ba8fd0c, a patch for
tree-ssa-sink, enabled the removal of basic blocks in ways that
affected the generated code for both of these tests, deviating from
the expectations of the tests.
The simplest case is that of -2, in which the edge unsplitting ends up
enabling a conditional return rather than a conditional branch to a
set-and-return block. That looks like an improvement to me, but the
condition in which the branch or the return takes place can be
reasonably reversed (and, with the current code, it is), I've relaxed
the pattern in the test so as to accept reversed and unreversed
conditions applied to return or branch opcodes.
The situation in -1 is a little more elaborate: conditional branches
based on FP compares in test_select_[78] are initially expanded with
CCFPE compare-and-cbranch on G{T,E}, but when ce2 turns those into a
cmove, because now we have a different fallthrough block, the
condition is reversed, and that lands us with a compare-and-cmove
sequence that needs CCFP for UNL{E,T}. The insn output reverses the
condition and swaps the cmove input operands, so the vcmp and vsel
insns come out the same except for the missing 'e' (for the compare
mode) in vcmp, so, since such reversals could have happened to any of
the tests depending on legitimate basic block layout, I've combined
the vcmp and vcmpe counts.
I see room for improving cmove sequence generation, e.g. trying direct
and reversed conditions and selecting the cheapest one (which would
require CCFP conditions to be modeled as more expensive than CCFPE),
or for some other machine-specific (peephole2?) optimization to turn
CCFP-requiring compare and cmove into CCFPE compare and swapped-inputs
cmove, but I haven't tried that.
for gcc/testsuite/ChangeLog
* gcc.target/arm/armv8_2-fp16-move-1.c: Combine vcmp and vcmpe
expected counts into a single pattern.
* gcc.target/arm/armv8_2-fp16-move-2.c: Accept conditional
return and reversed conditions.
The test uses arm_hard_ok and arm_softfp_ok as if they were mutually
exclusive, but they test whether the corresponding -mfloat-abi= flag
is usable, not whether it is in effect, so it is possible for both to
pass, and then the test comes out with incorrect expectations
whichever the default float-abi is.
Separate the test into hard and softfp variants, and extend the softfp
variant to accept both ARM and Thumb opcodes; it unwarrantedly assumed
the latter.
for gcc/testsuite/ChangeLog
PR target/51534
* gcc.target/arm/pr51534.c: Split softfp variant into...
* gcc.target/arm/pr51534s.c: ... this, and support ARM too.
Back in September last year, some of the vmsr and vmrs patterns had an
extraneous blank removed, and the case of register names lowered, but
another instance remained, and so did a testcase.
for gcc/ChangeLog
* config/arm/vfp.md (*thumb2_movsi_vfp): Drop blank after tab
after vmsr and vmrs, and lower the case of P0.
for gcc/testsuite/ChangeLog
* gcc.target/arm/acle/cde-mve-full-assembly.c: Drop blank
after tab after vmsr, and lower the case of P0.
The pr104882.c test is an execution test, but arm_v8_1m_mve_ok only
tests for compile-time support. Add a requirement for mve hardware.
for gcc/testsuite/ChangeLog
PR target/104882
* gcc.target/arm/simd/pr104882.c: Require mve hardware.
In order to fix PR100295, r13-4730-g18499b9f848707 attempted to make
extract_local_specs walk the given pattern twice, ignoring unevaluated
operands the first time around so that we prefer to process a local
specialization in an evaluated context if it appears in one (we process
each local specialization once even if it appears multiple times in the
pattern).
But there's a thinko in the patch, namely that we don't actually walk
the pattern twice since we don't clear the visited set for the second
walk (to avoid processing a local specialization twice) and so the root
node (and any node leading up to an unevaluated operand) is considered
visited already. So the patch effectively made extract_local_specs
ignore unevaluated operands altogether, which this testcase demonstrates
isn't quite safe (extract_local_specs never sees 'aa' and we don't record
its local specialization, so later we try to specialize 'aa' on the spot
with the args {{int},{17}} which causes us to nonsensically substitute
its auto with 17.)
This patch fixes this by refining the second walk to start from the
trees we skipped over during the first walk.
PR c++/108998
gcc/cp/ChangeLog:
* pt.cc (el_data::skipped_trees): New data member.
(extract_locals_r): Push to skipped_trees any unevaluated
contexts that we skipped over.
(extract_local_specs): For the second walk, start from each
tree in skipped_trees.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-generic11.C: New test.
This is a follow-up to commit a4c6bd0821
introducing a runtime check for alignment for 16 byte atomic
compare-exchange, load, and store.
libatomic/ChangeLog:
* config/s390/cas_n.c: New file.
* config/s390/load_n.c: New file.
* config/s390/store_n.c: New file.
The following patch fixes 2 issues with the -Wnonnull warning.
One, fixed by the second hunk, is that the warning wording is bogus
since r11-3305, instead of printing
warning: argument 1 to ‘int[static 7]’ is null where non-null expected [-Wnonnull]
it prints
warning: argument 1 to ‘int[static 28]’ is null where non-null expected [-Wnonnull]
access_size is measured in bytes, so obviously will be correct as array
number of elements only if it is 1 byte element array.
In the function, access_nelts is either constant (if sizidx == -1) or
when the array size is determined by some other parameter, I believe a value
passed to that argument.
Later on we query the range of it:
if (get_size_range (m_ptr_qry.rvals, access_nelts, stmt, sizrng, 1))
which I bet must just return accesS_nelts in sizrng[0] and [1] if it is
constant. access_size is later computed as:
tree access_size = NULL_TREE;
if (tree_int_cst_sgn (sizrng[0]) >= 0)
{
if (COMPLETE_TYPE_P (argtype))
{
...
wide_int minsize = wi::to_wide (sizrng[0], prec);
minsize *= wi::to_wide (argsize, prec);
access_size = wide_int_to_tree (sizetype, minsize);
}
}
else
access_size = access_nelts;
}
and immediately after this the code does:
if (integer_zerop (ptr))
{
if (sizidx >= 0 && tree_int_cst_sgn (sizrng[0]) > 0)
{
some other warning wording
}
else if (access_size && access.second.static_p)
{
this spot
}
}
So, because argtype is complete, access_size has been multiplied by
argsize, but in case of this exact warning ("this spot" above)
I believe access_nelts must be really constant, otherwise
"some other warning wording" would handle it. So, I think access_nelts
is exactly what we want to print there.
The other problem is that since the introduction of -Wdangling-pointer
in r12-6606, the pass has early and late instances and while lots of
stuff in the pass is guarded on being done in the late pass only,
this particular function is not, furthermore it is emitting two different
warnings in a loop and already messes up with stuff like clearing
warning suppression for one of the warning (ugh!). The end effect is
that we warn twice about the same problem, once in the early and once in
the late pass. Now, e.g. with -O2 -Wall we warn just once, during the
early pass, as it is then optimized away, so I think just making this
late warning only wouldn't be best. This patch instead returns early
if either of the warnings is suppressed on the call stmt already.
I think if one of the passes warned on it already (even if say on some other
argument), then warning again (even on some other argument) is unnecessary,
if both problems are visible in the same pass we'll still warn about both.
2023-03-03 Jakub Jelinek <jakub@redhat.com>
PR c/108986
* gimple-ssa-warn-access.cc (pass_waccess::maybe_check_access_sizes):
Return immediately if OPT_Wnonnull or OPT_Wstringop_overflow_ is
suppressed on stmt. For [static %E] warning, print access_nelts
rather than access_size. Fix up comment wording.
* gcc.dg/Wnonnull-8.c: New test.
When compiling on a system where binutils do not yet support the 'z16'
name assembling fails with -march=native on a z16 machine.
Currently, this is interpreted as -march=z16. This patch uses -march=arch14
instead.
gcc/ChangeLog:
* config/s390/driver-native.cc (s390_host_detect_local_cpu): Use
arch14 instead of z16.
We seem to flip flop between the "high" and "not low" variants of load on
condition. Accept both in the affected test cases.
gcc/testsuite/ChangeLog:
* gcc.target/s390/ifcvt-two-insns-bool.c: Allow "high" and
"not low or equal" load on condition variant.
* gcc.target/s390/ifcvt-two-insns-int.c: Dito.
* gcc.target/s390/ifcvt-two-insns-long.c: Dito.
This changes SLP test expectations. As we only vectorize when no more
than one rgroup is present, no vectorization is performed.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/slp-3.c: Adapt test expectation.
* gcc.dg/vect/slp-multitypes-11.c: Likewise.
* gcc.dg/vect/slp-perm-8.c: Likewise.
Change define_constraint to define_memory_constraint where appropriate
to fix LRA for moxie.
gcc/ChangeLog:
* config/moxie/constraints.md (A, B, W): Change
define_constraint to define_memory_constraint.
The driver emits a warning when -fstack-check and
-fstack-clash-protection are used together, but the message refers to
"-fstack-clash_protection" (underline instead of dash).
gcc/ChangeLog:
* toplev.cc (process_options): Fix the spelling of
"-fstack-clash-protection".
Partial PRE ends up miscompiling the testcase in PR109002, likely
involving a corner case when inifinite loops are involved. The
following avoids the miscompilation by addressing a long-standing
oddity that manifests in odd partial partial redundancies eliminated
that are full redundancies. The oddity is that while we properly
PHI translate the PA_IN set from the successors when computing
PA_OUT but we fail to do the same for ANTIC_IN which is supposed
to be unioned. That results in expressions with wrong virtual
operands being placed in the PA_OUT/IN sets and the pruning
machinery to go wrong because it assumes the expressions in the
sets have virtual operands that are valid in the respective blocks.
PR tree-optimization/109002
* tree-ssa-pre.cc (compute_partial_antic_aux): Properly
PHI-translate ANTIC_IN.
* gcc.dg/torture/pr109002.c: New testcase.
Fix memory leak of cmdline buffer and refactor to have
cleanup code appear once for all exit cases.
libiberty/ChangeLog:
* pex-win32.c (win32_spawn): Fix memory leak of cmdline
buffer and refactor to have cleanup code appear once
for all exit cases.
Signed-off-by: Jonathan Yong <10walls@gmail.com>
gimple_fold_builtin_fputs when folding fputs into fwrite emits the third
argument (INTEGER_CST) with incorrect type - get_maxval_strlen or c_strlen
return ssizetype, while fwrite argument is size_type_node.
The following patch fixes that, I've skimmed through the rest of
gimple-fold.cc and in all other places get_maxval_strlen/c_strlen result
was fold_converted to size_type_node already (or GIMPLE cast stmt has been
emitted directly etc.).
2023-03-03 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/108988
* gimple-fold.cc (gimple_fold_builtin_fputs): Fold len to
size_type_node before passing it as argument to fwrite. Formatting
fixes.
The following puts a hard limit on the inherently quadratic STV chain
discovery. Without a limit for the compiler.i testcase in PR26854
we see at -O2
machine dep reorg : 574.45 ( 53%)
with release checking while with the proposed limit it's
machine dep reorg : 2.86 ( 1%)
PR target/108738
* config/i386/i386.opt (--param x86-stv-max-visits): New param.
* doc/invoke.texi (--param x86-stv-max-visits): Document it.
* config/i386/i386-features.h (scalar_chain::max_visits): New.
(scalar_chain::build): Add bitmap parameter, return boolean.
(scalar_chain::add_insn): Likewise.
(scalar_chain::analyze_register_chain): Likewise.
* config/i386/i386-features.cc (scalar_chain::scalar_chain):
Initialize max_visits.
(scalar_chain::analyze_register_chain): When we exhaust
max_visits, abort. Also abort when running into any
disallowed insn.
(scalar_chain::add_insn): Propagate abort.
(scalar_chain::build): Likewise. When aborting amend
the set of disallowed insn with the insns set.
(convert_scalars_to_vector): Adjust. Do not convert aborted
chains.
When combining -g1 with -flto we run into the DIE location annotation
machinery for globals calling dwarf2out_late_global_decl but not
having any early generated DIE for function scope statics. In
this process we'd generate a limbo DIE since also the function scope
doesn't have any early generated DIE. The limbo handling then tries
to force a DIE for the context chain which ultimatively fails and
ICEs at the std namespace decl because at -g1 we don't represent that.
The following avoids this situation by making sure to never generate
any DIEs from dwarf2out_late_global_decl in the in_lto_p path
for function scope globals but rely on DIE generation for
the function to output a DIE for the local static (which doesn't
happen for -g1).
I explored a lot of other options to fix this but in the end this
seems to be the most spot-on fix with the least risk of unwanted
effects.
PR debug/108772
* dwarf2out.cc (dwarf2out_late_global_decl): Do not
generate a DIE for a function scope static.
* g++.dg/lto/pr108772_0.C: New testcase.
The test is compatible with clang as well as gcc, but ISTM that
testing for the __clang__ macro is just as potentially error-prone as
macros that used to be GCC-specific are now defined in compilers that
aim for GCC compatibility. Use a __has_include feature test instead.
for gcc/testsuite/ChangeLog
PR c++/100127
* g++.dg/coroutines/pr100127.C: Test for header rather than
compiler macro.
* g++.dg/coroutines/pr100772-a.C: Likewise.
* g++.dg/coroutines/pr100772-b.C: Likewise.
We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and
wchar_t mapped to the same underlying type, but this caused a glitch
in Wstringop-overflow-6.C: on vxworks, wint_t is typedef'ed to
wchar_t, headers got included in the test that declared functions that
take wint_t parameters, and those conflicted with the builtin
declarations that had wint_t mapped to the underlying integral type.
The problem is that, in C++, wchar_t is a distinct type. Having
wint_t be a typedef to wchar_t in the headers, but a typedef to
wchar_t's underlying integral type in builtins, makes for mismatches
between the declarations.
This patch defines WINT_TYPE to "wchar_t" for vxworks, and adjusts the
fallout, namely:
- since wchar_t may not have been defined yet when
c_common_nodes_and_builtins runs, use the node already reserved for
wchar_t for wint_t when WINT_TYPE is defined to wchar_t.
- for the same reason, when WINT_TYPE is wchar_t and we're not
compiling C++ where wchar_t is a compiler built-in, define
__WINT_TYPE__ to WCHAR_TYPE rather than WINT_TYPE, because wchar_t
may not even be defined in the translation unit.
- recognize and handle wchar_type_node when type_suffix is called for
wint_type_node.
for gcc/ChangeLog
* config/vx-common.h (WINT_TYPE): Alias to "wchar_t".
for gcc/c-family/ChangeLog
* c-common.cc (c_common_nodes_and_builtins): Take
wchar_type_node for wint_type_node when aliased.
(c_stddef_cpp_builtins): Define __WINT_TYPE__, when aliased to
wchar_t, to the underlying type rather than wchar_t in
non-C++.
* c-cppbuiltin.cc (type_suffix): Handle wchar_type_node.
When TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, when
we warn about comparing a pointer-to-member-function with NULL, we
also warn about comparing the pointer-to-function extracted from it
with NULL, which is redundant. Suppress the redundant warning.
for gcc/cp/ChangeLog
* typeck.cc (cp_build_binary_op): Suppress redundant warning
for pfn null test in pmfn test with vbit-in-delta.
tm.texi says for BIGGEST_ALIGNMENT (from which
__BIGGEST_ALIGNMENT__ is derived): "Biggest alignment that
any data type can require on this machine, in bits."
That is, using that value might be too strict for alignment
of *functions* and CRIS requires at least 16-bit alignment
for functions. But, one purpose of the test is to test that
alignment can be set to a large but valid value, so pick
512, which has some use as a historically required alignment
for certain I/O descriptors.
* gcc.dg/attr-aligned.c: Adjust comment for ALIGN_MAX_STATIC.
(ALIGN_MAX_STATIC): Set to 512 for CRIS.
Const and immutable types are built as variants of the type they are
derived from, and TYPE_STUB_DECL is not set for these variants.
PR d/108877
gcc/d/ChangeLog:
* imports.cc (ImportVisitor::visit (EnumDeclaration *)): Call
make_import on TYPE_MAIN_VARIANT.
(ImportVisitor::visit (AggregateDeclaration *)): Likewise.
(ImportVisitor::visit (ClassDeclaration *)): Likewise.
gcc/testsuite/ChangeLog:
* gdc.dg/imports/pr108877a.d: New test.
* gdc.dg/pr108877.d: New test.
The D front-end implementation got fixed in upstream, add test to the
gdc testsuite to check we don't regress on it.
PR d/108167
gcc/testsuite/ChangeLog:
* gdc.dg/pr108167.d: New test.
When comparing two vectors, the type of vector was used as the result of
the condition result. This meant that for floating point comparisons,
each value would either be `0.0' or `-1.0' reinterpreted as an integer,
not the expected integral bitmask values `0' and `-1'.
Instead, use the comparison type determined by truth_type_for as the
result of the comparison. If a reinterpret is later required by the
final conversion for generating CmpExp, it is still only going to
reinterpret one integer kind as another.
PR d/108945
gcc/d/ChangeLog:
* d-codegen.cc (build_boolop): Evaluate vector comparison as
the truth_type_for vector type.
gcc/testsuite/ChangeLog:
* gdc.dg/pr108945.d: New test.
The newly added dg-warning directive was missing the comment argument,
so the target selector was treated as comment and the warning was expected
on all targets when it should be expected only on llp64 targets.
2023-03-03 Jakub Jelinek <jakub@redhat.com>
PR testsuite/108991
* gcc.dg/memchr-3.c: Add missing comment argument to dg-warning
before target selector.
_Float16 and decltype(0.0bf16) types are on x86 supported only with
-msse2. On x86_64 that is the default, but on ia32 it is not.
We should still emit fundamental type tinfo for those types in
libsupc++.a/libstdc++.*, regardless of whether libsupc++/libstdc++
is compiled with -msse2 or not, as user programs can be compiled
with different ISA flags from libsupc++/libstdc++ and if they
are compiled with -msse2 and use std::float16_t or std::bfloat16_t
and need RTTI for it, it should work out of the box. Furthermore,
libstdc++ ABI on ia32 shouldn't depend on whether the library
is compiled with -mno-sse or -msse2.
Unfortunately, just hacking up libsupc++ Makefile/configure so that
a single source is compiled with -msse2 isn't appropriate, because
that TU emits also code and the code should be able to run on CPUs
which libstdc++ supports. We could add [[gnu::attribute ("no-sse2")]]
there perhaps conditionally, but it all gets quite ugly.
The following patch instead adds a target hook which allows the backend
to temporarily tweak registered types such that emit_support_tinfos
emits whatever is needed.
Additionally, it makes emit_support_tinfos_1 call emit_tinfo_decl
immediately, so that temporarily created dummy types for emit_support_tinfo
purposes only can be nullified again afterwards. And removes the
previous fallback_* types used for dfloat*_type_node tinfos even when
decimal types aren't supported.
2023-03-03 Jakub Jelinek <jakub@redhat.com>
PR target/108883
gcc/
* target.h (emit_support_tinfos_callback): New typedef.
* targhooks.h (default_emit_support_tinfos): Declare.
* targhooks.cc (default_emit_support_tinfos): New function.
* target.def (emit_support_tinfos): New target hook.
* doc/tm.texi.in (emit_support_tinfos): Document it.
* doc/tm.texi: Regenerated.
* config/i386/i386.cc (ix86_emit_support_tinfos): New function.
(TARGET_EMIT_SUPPORT_TINFOS): Redefine.
gcc/cp/
* cp-tree.h (enum cp_tree_index): Remove CPTI_FALLBACK_DFLOAT*_TYPE
enumerators.
(fallback_dfloat32_type, fallback_dfloat64_type,
fallback_dfloat128_type): Remove.
* rtti.cc (emit_support_tinfo_1): If not emitted already, call
emit_tinfo_decl and remove from unemitted_tinfo_decls right away.
(emit_support_tinfos): Move &dfloat*_type_node from fundamentals array
into new fundamentals_with_fallback array. Call emit_support_tinfo_1
on elements of that array too, with the difference that if
the type is NULL, use a fallback REAL_TYPE for it temporarily.
Drop the !targetm.decimal_float_supported_p () handling. Call
targetm.emit_support_tinfos at the end.
* mangle.cc (write_builtin_type): Remove references to
fallback_dfloat*_type. Handle bfloat16_type_node mangling.
This is the 2nd attempt to fix PR90706. IRA calculates wrong AVR
costs for moving general hard regs of SFmode. This was the reason for
spilling a pseudo in the PR. In this patch we use smaller move cost
of hard reg in its natural and operand modes.
PR rtl-optimization/90706
gcc/ChangeLog:
* ira-costs.cc: Include print-rtl.h.
(record_reg_classes, scan_one_insn): Add code to print debug info.
(record_operand_costs): Find and use smaller cost for hard reg
move.
gcc/testsuite/ChangeLog:
* gcc.target/avr/pr90706.c: New.
Calls to vectorized versions of routines in the math library will now
be inserted when vectorizing code containing supported math functions.
2023-03-02 Kwok Cheung Yeung <kcy@codesourcery.com>
Paul-Antoine Arras <pa@codesourcery.com>
gcc/
* builtins.cc (mathfn_built_in_explicit): New.
* config/gcn/gcn.cc: Include case-cfn-macros.h.
(mathfn_built_in_explicit): Add prototype.
(gcn_vectorize_builtin_vectorized_function): New.
(gcn_libc_has_function): New.
(TARGET_LIBC_HAS_FUNCTION): Define.
(TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION): Define.
gcc/testsuite/
* gcc.target/gcn/simd-math-1.c: New testcase.
* gcc.target/gcn/simd-math-2.c: New testcase.
libgomp/
* testsuite/libgomp.c/simd-math-1.c: New testcase.
We should also fold the overall initializer passed to cp_fully_fold_init
with mce_false, which allows folding of the copy-initialization of
'a1' in the below testcase (the initializer here is an AGGR_INIT_EXPR).
Unfortunately this doesn't help with direct- or default-initialization
because we don't call cp_fully_fold_init in that case, and even if we
did the initializer in that case is expressed as a bare CALL_EXPR
instead of an AGGR_INIT_EXPR, which cp_fully_fold_init can't really
fold.
PR c++/108243
PR c++/97553
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_fully_fold): Add an internal overload that
additionally takes and propagate an mce_value parameter, and
define the existing public overload in terms of it.
(cp_fully_fold_init): Pass mce_false to cp_fully_fold.
gcc/testsuite/ChangeLog:
* g++.dg/opt/is_constant_evaluated3.C: New test.
According to [basic.start.static]/2 and [expr.const]/2, a variable
with static storage duration initialized with a constant initializer
has constant initialization, and such an initializer is manifestly
constant-evaluated.
For copy initialization, we're already getting this right because in
that case check_initializer would consistently call store_init_value,
which for TREE_STATIC variables calls fold_non_dependent_init with
m_c_e=true.
But for direct (or default) initialization, check_initializer doesn't
always call store_init_value. We instead however always call
maybe_constant_init from expand_default_init[1], albeit with m_c_e=false
which means we don't get the "manifestly constant-evaluated" part right
for non-copy-init.
This patch fixes this by setting m_c_e=true in maybe_constant_init for
static storage duration variables, mainly for benefit of the call
to maybe_constant_init from expand_default_init.
[1]: this maybe_constant_init call isn't reached in the copy-init
case because there init is a CONSTRUCTOR rather than a TREE_LIST,
and so we exit early from expand_default_init, returning an INIT_EXPR.
This INIT_EXPR is ultimately what causes us to consistently hit the
store_init_value code path from check_initializer in the copy-init case.
PR c++/108243
gcc/cp/ChangeLog:
* constexpr.cc (maybe_constant_init_1): Override
manifestly_const_eval to true if is_static.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/is-constant-evaluated14.C: New test.
gcc/analyzer/ChangeLog:
PR analyzer/108968
* region-model.cc (region_model::get_rvalue_1): Handle VAR_DECLs
with a DECL_HARD_REGISTER by returning UNKNOWN.
gcc/testsuite/ChangeLog:
PR analyzer/108968
* gcc.dg/analyzer/uninit-pr108968-register.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Before IMPORTED_DECL has been introduced in PR37410, we used to emit correct
DW_AT_decl_line on DW_TAG_imported_module on the testcase below, after that
change we haven't emitted it at all for a while and after some time
started emitting incorrect locus, in particular the location of } closing
the function.
The problem is that while we have correct EXPR_LOCATION on the USING_STMT,
when genericizing that USING_STMT into IMPORTED_DECL we don't copy the
location to DECL_SOURCE_LOCATION, so it gets whatever input_location happens
to be when it is created.
2023-03-02 Jakub Jelinek <jakub@redhat.com>
PR debug/108716
* cp-gimplify.cc (cp_genericize_r) <case USING_STMT>: Set
DECL_SOURCE_LOCATION on IMPORTED_DECL to expression location
of USING_STMT or input_location.
* g++.dg/debug/dwarf2/pr108716.C: New test.
