_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.
The loop body in the testcase contains an operation on invariants.
SLP detects this and can hoist/schedule the operation outside of
the loop. However, after the fix for PR96373, we would try to
apply a loop mask to this operation, even though the mask is
defined in the loop.
The patch does what Richi suggested in the PR: suppress the
masking for externs and constants.
gcc/
PR tree-optimization/108979
* tree-vect-stmts.cc (vectorizable_operation): Don't mask
operations on invariants.
gcc/testsuite/
PR tree-optimization/108979
* gfortran.dg/vect/pr108979.f90: New test.
-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,
template<typename T> struct A { };
class A<int> a;
it works by adding A<T> to the class2loc hash table while parsing the
class-head and then, while parsing the elaborate type-specifier, we
add A<int>. At the end of c_parse_file we go through the table and
warn about the class-key mismatches. In this PR we crash though; we
have
template<typename T> struct A {
template<typename U> struct W { };
};
struct A<int>::W<int> w; // #1
where while parsing A and #1 we've stashed
A<T>
A<T>::W<U>
A<int>::W<int>
into class2loc. Then in class_decl_loc_t::diag_mismatched_tags TYPE
is A<int>::W<int>, and specialization_of gets us A<int>::W<U>, which
is not in class2loc, so we crash on gcc_assert (cdlguide). But it's
OK not to have found A<int>::W<U>, we should just look one "level" up,
that is, A<T>::W<U>.
It's important to handle class specializations, so e.g.
template<>
struct A<char> {
template<typename U>
class W { };
};
where W's class-key is different than in the primary template above,
so we should warn depending on whether we're looking into A<char>
or into a different instantiation.
PR c++/106259
gcc/cp/ChangeLog:
* parser.cc (class_decl_loc_t::diag_mismatched_tags): If the first
lookup of SPEC didn't find anything, try to look for
most_general_template.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wmismatched-tags-11.C: New test.
This patch adds LEN_LOAD/LEN_STORE support for z13 and newer.
It defines a bias value of -1 and implements the LEN_LOAD and LEN_STORE
optabs.
Add vll/vstl testcases adapted from Power.
Also change expectations for SLP testcases with more than one rgroup.
gcc/ChangeLog:
* config/s390/predicates.md (vll_bias_operand): Add -1 bias.
* config/s390/s390.cc (s390_option_override_internal): Make
partial vector usage the default from z13 on.
* config/s390/vector.md (len_load_v16qi): Add.
(len_store_v16qi): Add.
gcc/testsuite/ChangeLog:
* gcc.target/s390/s390.exp: Add partial subdirectory.
* gcc.target/s390/vector/vec-nopeel-2.c: Change test
expectation.
* lib/target-supports.exp: Add s390.
* gcc.target/s390/vector/partial/s390-vec-length-1.h: New test.
* gcc.target/s390/vector/partial/s390-vec-length-2.h: New test.
* gcc.target/s390/vector/partial/s390-vec-length-3.h: New test.
* gcc.target/s390/vector/partial/s390-vec-length-7.h: New test.
* gcc.target/s390/vector/partial/s390-vec-length-epil-1.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-epil-2.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-epil-3.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-epil-7.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-epil-run-1.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-epil-run-2.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-epil-run-3.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-epil-run-7.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-full-1.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-full-2.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-full-3.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-full-7.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-full-run-1.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-full-run-2.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-full-run-3.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-full-run-7.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length-run-1.h: New test.
* gcc.target/s390/vector/partial/s390-vec-length-run-2.h: New test.
* gcc.target/s390/vector/partial/s390-vec-length-run-3.h: New test.
* gcc.target/s390/vector/partial/s390-vec-length-run-7.h: New test.
* gcc.target/s390/vector/partial/s390-vec-length-small.c: New test.
* gcc.target/s390/vector/partial/s390-vec-length.h: New test.
This patch fixes a missed review comment in an earlier patch using byte instead
of a 0 offset. Also improves the comment as suggested.
gcc/ChangeLog:
* simplify-rtx.cc (simplify_context::simplify_subreg): Use byte instead
of constant 0 offset.
convert_memory_address_addr_space_1 has two modes: one in which it
tries to create a self-contained RTL expression (which might fail)
and one in which it can emit new instructions where necessary.
When handling a CONST, the function recurses into the CONST's
operand and then constifies the result. But that's only valid if
the result is still a self-contained expression. If new instructions
have been emitted, the expression will refer to the (non-constant)
results of those instructions.
In the PR, this caused us to emit a nonsensical (const (reg ...))
REG_EQUAL note.
gcc/
PR tree-optimization/108603
* explow.cc (convert_memory_address_addr_space_1): Only wrap
the result of a recursive call in a CONST if no instructions
were emitted.
gcc/testsuite/
PR tree-optimization/108603
* gcc.target/aarch64/sve/pr108603.c: New test.
vectorizable_condition checks whether a COND_EXPR condition is used
elsewhere with a loop mask. If so, it applies the loop mask to the
COND_EXPR too, to reduce the number of live masks and to increase the
chance of combining the AND with the comparison.
There is also code to do this for inverted conditions. E.g. if
we have a < b ? c : d and something else is conditional on !(a < b)
(such as a load in d), we use !(a < b) ? d : c and apply the loop
mask to !(a < b).
This inversion relied on the function's bitop1/bitop2 mechanism.
However, that mechanism is skipped if the condition is split out of
the COND_EXPR as a separate statement. This meant that we could end
up using the inverse of the intended condition.
There is a separate way of negating the condition when a mask
is being applied (which is also used for EXTRACT_LAST reductions).
This patch uses that instead.
As well as the testcase, this fixes aarch64/sve/vcond_{4,17}_run.c.
gcc/
PR tree-optimization/108430
* tree-vect-stmts.cc (vectorizable_condition): Fix handling
of inverted condition.
gcc/testsuite/
PR tree-optimization/108430
* gcc.target/aarch64/sve/pr108430.c: New test.
In the following testcase we try to std::bit_cast a (pair of) integral
value(s) which has some non-zero bits in the place of x86 long double
(for 64-bit 16 byte type with 10 bytes actually loaded/stored by hw,
for 32-bit 12 byte) and starting with my PR104522 change we reject that
as native_interpret_expr fails on it. The PR104522 change extends what
has been done before for MODE_COMPOSITE_P (but those don't have any padding
bits) to all floating point types, because e.g. the exact x86 long double
has various bit combinations we don't support, like
pseudo-(denormals,infinities,NaNs) or unnormals. The HW handles some of
those as exceptional cases and others similarly to the non-pseudo ones.
But for the padding bits it actually doesn't load/store those bits at all,
it loads/stores 10 bytes. So, I think we should exempt the padding bits
from the reverse comparison (the native_encode_expr bits for the padding
will be all zeros), which the following patch does. For bit_cast it is
similar to e.g. ignoring padding bits if the destination is a structure
which has padding bits in there.
The change changed auto-init-4.c to how it has been behaving before the
PR105259 change, where some more VCEs can be now done.
2023-03-02 Jakub Jelinek <jakub@redhat.com>
PR c++/108934
* fold-const.cc (native_interpret_expr) <case REAL_CST>: Before memcmp
comparison copy the bytes from ptr to a temporary buffer and clearing
padding bits in there.
* gcc.target/i386/auto-init-4.c: Revert PR105259 change.
* g++.target/i386/pr108934.C: New test.
The PR108503 temporary DECL_HAS_VALUE_EXPR_P clearing code can ICE
during recovery, because cp_finish_decomp when it detects errors and
reports them clears DECL_HAS_VALUE_EXPR_P, clears DECL_VALUE_EXPR and
sets TREE_TYPE of the structured binding vars to error_mark_node.
The PR108503 code had an assertion that DECL_HAS_VALUE_EXPR_P is set
so that it can clear it and restore later.
The following patch allows DECL_HAS_VALUE_EXPR_P to be unset if
type is error_mark_node and doesn't set it again in that case.
2023-03-02 Jakub Jelinek <jakub@redhat.com>
PR c++/105839
* parser.cc (cp_convert_omp_range_for): Allow in assert
decomp_first_name without DECL_HAS_VALUE_EXPR_P if it has
error_mark_node type.
(cp_finish_omp_range_for): Don't set DECL_HAS_VALUE_EXPR_P back
on decls which have error_mark_node type.
* g++.dg/gomp/pr105839-1.C: New test.
* g++.dg/gomp/pr105839-2.C: New test.
For targets where the byte-wise structure element layout is
the same as for attribute-packed, you get a warning when
that's specified. Thus, expect a warning for such targets.
Note the exclusion of bitfields.
* g++.dg/ext/attr-copy-2.C: Fix for default_packed targets.
This fixes:
Running /x/gcc/testsuite/gcc.dg/dg.exp ...
...
FAIL: gcc.dg/attr-copy-6.c (test for excess errors)
for cris-elf, where gcc.log has:
Excess errors:
/x/gcc/testsuite/gcc.dg/attr-copy-6.c:91:3: error: 'fnoreturn_alias' aliased to undefined symbol 'fnoreturn_name'
Asm-declared identifiers need to prepend __USER_LABEL_PREFIX__
to the asm-name, something which is often overlooked because
it's empty for most targets. N.B: attribute-alias does not need
the same treatment. The identical construct added here, is in
several tests.
* gcc.dg/attr-copy-6.c: Prefix asm-declared name with
__USER_LABEL_PREFIX__.
Without this definition, the errno definition for newlib
isn't recognized as such, and these tests fail for newlib
targets:
FAIL: gcc.dg/analyzer/call-summaries-errno.c (test for warnings, line 16)
FAIL: gcc.dg/analyzer/call-summaries-errno.c (test for excess errors)
FAIL: gcc.dg/analyzer/errno-1.c (test for warnings, line 20)
FAIL: gcc.dg/analyzer/errno-1.c (test for excess errors)
FAIL: gcc.dg/analyzer/flex-without-call-summaries.c (test for excess errors)
FAIL: gcc.dg/analyzer/isatty-1.c (test for warnings, line 31)
FAIL: gcc.dg/analyzer/isatty-1.c (test for warnings, line 35)
FAIL: gcc.dg/analyzer/isatty-1.c (test for warnings, line 46)
FAIL: gcc.dg/analyzer/isatty-1.c (test for warnings, line 56)
FAIL: gcc.dg/analyzer/isatty-1.c (test for excess errors)
gcc/analyzer:
* kf.cc (register_known_functions): Add __errno function for newlib.
Looks like there's a failed assumption that
sizeof (union U { char u1[5]; int u2; float u3; }) == 8.
However, for "packed" targets like cris-elf, it's 5.
These two tests have always failed for cris-elf. I see from
https://gcc.gnu.org/pipermail/gcc-testresults/2023-February/777912.html
that they fail on pru-elf too, but I don't know if the cause
(and/or remedy) is the same.
IMHO this is preferred over the alternative; splitting up
that last line into two lines, like:
/* { dg-final { scan-tree-dump "temp4 = \
.DEFERRED_INIT \\(8, 2, \&\"temp4\"" "gimple" { target { ! default_packed } } } } */
/* { dg-final { scan-tree-dump "temp4 = \
.DEFERRED_INIT \\(5, 2, \&\"temp4\"" "gimple" { target default_packed } } } */
gcc/testsuite:
* c-c++-common/auto-init-7.c, c-c++-common/auto-init-8.c: Also
match targets where sizeof (union U) == 5, like "packed" targets.
Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't
been completed yet, but that doesn't work:
/* We can't lower this until the class is complete. */
if (!COMPLETE_TYPE_P (DECL_CONTEXT (member)))
return cst;
and then this unlowered PTRMEM_CST is used as EXPR in
tree op1 = build_nop (ptrdiff_type_node, expr);
and we crash in a subsequent cp_fold_convert which gets type=ptrdiff_type_node,
expr=PTRMEM_CST and does
else if (TREE_CODE (expr) == PTRMEM_CST
&& same_type_p (TYPE_PTRMEM_CLASS_TYPE (type),
PTRMEM_CST_CLASS (expr)))
where TYPE_PTRMEM_CLASS_TYPE (type) is going to crash since the type
is ptrdiff_type_node. We could just add a TYPE_PTRMEM_P check before
accessing TYPE_PTRMEM_CLASS_TYPE but I think it's nicer to explain why
we couldn't evaluate the expression.
PR c++/107574
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression): Emit an error when
a PTRMEM_CST cannot be evaluated.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/ptrmem-cst1.C: New test.
This patch introduces a convenience wrapper tsubst_scope for tsubst'ing
into a type with tf_qualifying_scope set, and makes suitable callers use
it instead of explicitly setting tf_qualifying_scope. This patch also
makes tsubst_copy immediately delegate to tsubst for all type trees,
which allows tsubst_copy to be oblivious to the tf_qualifying_scope flag.
gcc/cp/ChangeLog:
* pt.cc (tsubst_scope): Define.
(tsubst_decl) <case USING_DECL>: Call tsubst_scope instead of
calling tsubst_scope with tf_qualifying_scope set.
(tsubst_qualified_id): Call tsubst_scope instead of
calling tsubst with tf_qualifying_scope set.
(tsubst_copy): Immediately delegate to tsubst for all TYPE_P
trees. Remove tf_qualifying_scope manipulation.
<case SCOPE_REF>: Call tsubst_scope instead of calling
tsubst with tf_qualifying_scope set.
Previously, if the analyzer saw a call to a non-pure and non-const
built-in function that it didn't have explicit knowledge of the behavior
of, it would fall back to assuming that the builtin could have arbitrary
behavior, similar to a function defined outside of the current TU.
However, this only worked for BUILTIN_NORMAL functions that matched
gimple_builtin_call_types_compatible_p; for BUILT_IN_FRONTEND and
BUILT_IN_MD, and for mismatched types the analyzer would erroneously
assume that the builtin had no side-effects, leading e.g. to
PR analyzer/107565, where the analyzer falsely reported that x
was still uninitialized after this target-specific builtin:
_1 = __builtin_ia32_rdrand64_step (&x);
This patch generalizes the handling to cover all classes of builtin,
fixing the above false positive.
Unfortunately this patch regresses gcc.dg/analyzer/pr99716-1.c due to
the:
fprintf (fp, "hello");
being optimized to:
__builtin_fwrite ("hello", 1, (ssizetype)5, fp_6);
and the latter has gimple_builtin_call_types_compatible_p return false,
whereas the original call had it return true. I'm assuming that this is
an optimization bug, and have filed it as PR middle-end/108988. The
effect on the analyzer is that it fails to recognize the call to
__builtin_fwrite and instead assumes arbitraty side-effects (including
that it could call fclose on fp, hence the report about the leak goes
away).
I tried various more involved fixes with new heuristics for handling
built-ins that aren't explicitly covered by the analyzer, but those
fixes tended to introduce many more regressions, so I'm going with this
simpler fix.
gcc/analyzer/ChangeLog:
PR analyzer/107565
* region-model.cc (region_model::on_call_pre): Flatten logic by
returning early. Consolidate logic for detecting const and pure
functions. When considering whether an unhandled built-in
function has side-effects, consider all kinds of builtin, rather
than just BUILT_IN_NORMAL, and don't require
gimple_builtin_call_types_compatible_p.
gcc/testsuite/ChangeLog:
PR analyzer/107565
* gcc.dg/analyzer/builtins-pr107565.c: New test.
* gcc.dg/analyzer/pr99716-1.c (test_2): Mark the leak as xfailing.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
This is consistent with the behaviour of glibc, which assumes UTC when
/etc/localtime and TZ do not identify a valid time zone. The fallback
tzdb used when no valid tzdata exists always contains the UTC zone, so
this change means we have a valid tzdb and valid current zone even in
the degenerate case.
With this default we no longer need the AIX-specific kluge to try and
identify TZ values specifying a 0-offset zone. We can just use the UTC
default for those, as it has the same effect.
It's still possible for chrono::current_zone() to fail, because the user
could have provided a custom tzdata.zi file which doesn't contain the
UTC time zone, so the "UTC" default would fail to find a valid zone, and
throw an exception. That's just user error, they should not provide bad
data and expect reasonable behaviour.
libstdc++-v3/ChangeLog:
* src/c++20/tzdb.cc (chrono::tzdb::current_zone()) Use "UTC" if
current time zone cannot be determined.
* testsuite/std/time/tzdb/1.cc: Remove conditions based on
HAVE_TZDB macro and test all members unconditionally.
Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts. This shouldn't make a difference
here since the array sizes are constant literals, except they're expressed
as NON_LVALUE_EXPR location wrappers around INTEGER_CST, wrappers which
used to get stripped as part of constant evaluation and now no longer do.
Moreover it means build_vec_init can't constant fold the MINUS_EXPR
'maxindex' passed from build_new_1 when in an unevaluated context (since
it tries reducing it via maybe_constant_value called with mce_unknown).
This patch fixes these issues by making maybe_constant_value (and
fold_non_dependent_expr) try folding an unevaluated non-manifestly-constant
operand via fold(), as long as it simplifies to a simple constant, rather
than doing no simplification at all. This covers e.g. simple arithmetic
and casts including stripping of location wrappers around INTEGER_CST.
In passing, this patch also fixes maybe_constant_value to avoid constant
evaluating an unevaluated operand when called with mce_false, by adjusting
the early exit test appropriately.
Co-authored-by: Jason Merrill <jason@redhat.com>
PR c++/108219
PR c++/108218
gcc/cp/ChangeLog:
* constexpr.cc (fold_to_constant): Define.
(maybe_constant_value): Move up early exit test for unevaluated
operands. Try reducing an unevaluated operand to a constant via
fold_to_constant.
(fold_non_dependent_expr_template): Add early exit test for
CONSTANT_CLASS_P nodes. Try reducing an unevaluated operand
to a constant via fold_to_constant.
* cp-tree.h (fold_to_constant): Declare.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/new6.C: New test.
* g++.dg/cpp2a/concepts-new1.C: New test.
With volatile, two 'x.data' comp refs aren't regarded as identical,
causing that the two items in the first map of
map(to:x.a, x.a.data) map(pset: x.a.data)
end up in separate 'map(struct:x)', which will cause a later ICE.
Solution: Ignore side effects when checking the operands in the hash
for being equal. (Do so by creating a variant of tree_operand_hash
that calls operand_equal_p with OEP_MATCH_SIDE_EFFECTS.)
gcc/ChangeLog:
PR middle-end/108545
* gimplify.cc (struct tree_operand_hash_no_se): New.
(omp_index_mapping_groups_1, omp_index_mapping_groups,
omp_reindex_mapping_groups, omp_mapped_by_containing_struct,
omp_tsort_mapping_groups_1, omp_tsort_mapping_groups,
oacc_resolve_clause_dependencies, omp_build_struct_sibling_lists,
gimplify_scan_omp_clauses): Use tree_operand_hash_no_se instead
of tree_operand_hash.
gcc/testsuite/ChangeLog:
PR middle-end/108545
* c-c++-common/gomp/map-8.c: New test.
* gfortran.dg/gomp/map-9.f90: New test.
gcc/analyzer/ChangeLog:
PR analyzer/108935
* infinite-recursion.cc (contains_unknown_p): New.
(sufficiently_different_region_binding_p): New function, splitting
out inner loop from...
(sufficiently_different_p): ...here. Extend detection of unknown
svalues to also include svalues that contain unknown. Treat
changes in frames below the entry to the recursion as being
sufficiently different to reject being an infinite recursion.
gcc/testsuite/ChangeLog:
PR analyzer/108935
* gcc.dg/analyzer/infinite-recursion-pr108935-1.c: New test.
* gcc.dg/analyzer/infinite-recursion-pr108935-1a.c: New test.
* gcc.dg/analyzer/infinite-recursion-pr108935-2.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
PCHs can now be relocated, so the size limit makes no sense any more.
This patch was submited to MSYS2 9 months ago for GCC 12. No issue has been reported so far.
Reference: 717d5a5a09/mingw-w64-gcc/0010-Fix-using-large-PCH.patch
Signed-off-by: LIU Hao <lh_mouse@126.com>
gcc/ChangeLog:
PR pch/14940
* config/i386/host-mingw32.cc (mingw32_gt_pch_get_address):
Remove the size limit `pch_VA_max_size`
Signed-off-by: Jonathan Yong <10walls@gmail.com>
For is_device_ptr, optional checks should only be done before calling
libgomp, afterwards they are NULL either because of absent or, by
chance, because it is unallocated or unassociated (for pointers/allocatables).
Additionally, it fixes an issue with explicit mapping for 'type(c_ptr)'.
PR middle-end/108546
gcc/fortran/ChangeLog:
* trans-openmp.cc (gfc_trans_omp_clauses): Fix mapping of
type(C_ptr) variables.
gcc/ChangeLog:
* omp-low.cc (lower_omp_target): Remove optional handling
on the receiver side, i.e. inside target (data), for
use_device_ptr.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/is_device_ptr-3.f90: New test.
* testsuite/libgomp.fortran/use_device_ptr-optional-4.f90: New test.
I think it is useful to cover also this, rather than just arrays at the
flexible array member positions.
2023-03-01 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/108894
* c-c++-common/ubsan/bounds-16.c: New test.
When these tree codes were introduced, expand_debug_expr hasn't been
updated to handle them. For the VEC_*_EXPR we currently mostly punt, the
non-vector ones can be handled easily. In release compilers this doesn't
ICE, but with checking we ICE so that we make sure to handle all the needed
tree codes there.
2023-03-01 Jakub Jelinek <jakub@redhat.com>
PR debug/108967
* cfgexpand.cc (expand_debug_expr): Handle WIDEN_{PLUS,MINUS}_EXPR
and VEC_WIDEN_{PLUS,MINUS}_{HI,LO}_EXPR.
* g++.dg/debug/pr108967.C: New test.
The r13-2965-g73d9b0e5947e16 change changed the line touched in this patch
from
return RECUR (tmp, want_rval);
to
return RECUR (DECL_INITIAL (tmp), want_rval);
This is on DECL_EXPR handling code, where tmp can be lots of different
trees and DECL_INITIAL unfortunately also means different things on
different trees.
It is the initializer on VAR_DECL, DECL_ARG_TYPE on PARM_DECLs (though
those are unlikely to have DECL_EXPRs), for FUNCTION_DECLs the body,
..., USING_DECL_DECLS on USING_DECLs and DECL_FRIENDLIST on TYPE_DECLs.
The testcase below ICEs because we have a DECL_EXPR for TYPE_DECL
which has non-NULL DECL_FRIENDLIST and we certainly can't recurse on
the friend list.
The following patch will RECUR on DECL_INITIAL only for VAR_DECLs and
for anything else just return true.
2023-03-01 Jakub Jelinek <jakub@redhat.com>
PR c++/108606
* constexpr.cc (potential_constant_expression_1) <case DECL_EXPR>:
Only recurse on DECL_INITIAL (tmp) if tmp is a VAR_DECL, otherwise
just return true.
* g++.dg/cpp1y/pr108606.C: New test.
The function slpeel_can_duplicate_loop_p fails to verify we can
copy blocks, instead slpeel_tree_duplicate_loop_to_edge_cfg does
but that's too late. The following fixes this, also simplifying
error reporting which is somewhat pointless if we ICE immediately.
PR tree-optimization/108970
* tree-vect-loop-manip.cc (slpeel_can_duplicate_loop_p):
Check we can copy the BBs.
(slpeel_tree_duplicate_loop_to_edge_cfg): Avoid redundant
check.
(vect_do_peeling): Streamline error handling.
* gcc.dg/pr108970.c: New testcase.
Without LTO, TYPE_POINTER_TO/TYPE_REFERENCE_TO chains are only maintained
inside of build_{pointer,reference}_type_for_mode and those routines
ensure that the pointer/reference type added to the chain is really
without any user attributes (unless something would modify the types
in place, but that would be wrong).
Now, LTO adds stuff to these chains in lto_fixup_prevailing_type but
doesn't guarantee that. The testcase in the PR (which I'm not including
for testsuite because when (I hope) the aarch64 backend bug will be fixed,
the testcase would work either way) shows a case where user has
TYPE_USER_ALIGN type with very high alignment, as there aren't enough
pointers to float in the code left that one becomes the prevailing one
(because types with attributes are created with build_distinct_type_copy
and thus their own TYPE_MAIN_VARIANTs), lto_fixup_prevailing_type puts
it into the TYPE_POINTER_TO chain of float and later on during expansion
of __builtin_cexpif expander uses build_pointer_type (float_type_node)
to emit a sincosf call and instead of getting a normal pointer type gets
this non-standard one.
The following patch fixes that by not adding into those chains
types with TYPE_ATTRIBUTES, and for REFERENCE_TYPEs not even with
TYPE_REF_IS_RVALUE - while the C++ FE adds those into those chains,
it always ensures such a type goes immediately after the corresponding
non-TYPE_REF_IS_RVALUE REFERENCE_TYPE with the same
mode/TYPE_REF_CAN_ALIAS_ALL, so LTO would need to ensure that too, but
TYPE_REF_IS_RVALUE types are looked that way only in the C++ FE.
2023-03-01 Jakub Jelinek <jakub@redhat.com>
PR target/108910
* lto-common.cc (lto_fixup_prevailing_type): Don't add t to
TYPE_POINTER_TO or TYPE_REFERENCE_TO chain if it has
TYPE_ATTRIBUTES or is TYPE_REF_IS_RVALUE.
When we end up with a widen-sum with an invariant smaller operand
the reduction code uses a wrong vector type for it, causing
IL checking ICEs. The following fixes that and the inefficiency
of using a widen-sum with a widenend invariant operand as well
by actually performing the check the following comment wants.
PR tree-optimization/108950
* tree-vect-patterns.cc (vect_recog_widen_sum_pattern):
Check oprnd0 is defined in the loop.
* tree-vect-loop.cc (vectorizable_reduction): Record all
operands vector types, compute that of invariants and
properly update their SLP nodes.
* gcc.dg/vect/pr108950.c: New testcase.
Before r13-4894, if 64 bit is explicitly specified, option
powerpc64 is explicitly enabled too; while if 64 bit is
implicitly enabled and there is no explicit setting for
option powerpc64, option powerpc64 is eventually enabled
or not would rely on the default value of the used cpu.
It's initially set as the setting for 64 bit, but later if
the used cpu doesn't have powerpc64 supported by default,
it gets cleared.
To keep it consistent with before (also the relevant error/
warning messages), this patch is to allow that powerpc64
can be unset if 64 bit is enabled implicitly, and only stop
it from being unset if 64 bit is enabled explicitly.
Note that since the behaviors are different for implicit
and explicit 64 bit, I failed to construct one solid test
case since it becomes fragile once RUNTESTFLAGS specifying
-m64 explicitly.
PR target/108240
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_option_override_internal): Allow
implicit powerpc64 setting to be unset if 64 bit is enabled implicitly.
Investigating analyzer testsuite errors for cris-elf. The same are
seen for pru-elf according to posts to gcc-testresults@.
The test fd-access-mode-target-headers.c uses the analyzer
"sm-fd" which for this use requires (e.g.) that constants
O_ACCMODE, O_RDONLY and O_WRONLY are defined as literal
constants. While for glibc, O_ACCMODE is defined as:
#define O_ACCMODE 0003
in newlib, it's defined as:
#define O_ACCMODE (O_RDONLY|O_WRONLY|O_RDWR)
and the analyzer is not able to make use of an expression
like this (even though O_RDONLY, O_WRONLY and O_RDWR are
defined as literal constants and the whole evaluates to 3).
Better do as for AIX and skip this test.
testsuite:
* gcc.dg/analyzer/fd-access-mode-target-headers.c: Skip for
newlib targets too.
Here we're treating deeming the non-dependent variable template-id
tag<int> as dependent ever since r226642 gave variable TEMPLATE_ID_EXPR
an empty type, which causes the call to finish_template_variable from
finish_id_expression_1 to be unreachable at template parse time. Thus
we're led into thinking tag<int>.var<void> refers to a dependent name.
This patch fixes this by making finish_id_expression_1 instantiate a
variable template-id as long as it's not dependent according to the
dependence test in lookup_and_finish_template_variable rather than
according to type_dependent_expression_p.
PR c++/108848
gcc/cp/ChangeLog:
* pt.cc (finish_template_variable): Move dependence check
to here from ...
(lookup_and_finish_template_variable): ... here.
* semantics.cc (finish_id_expression_1): Call
finish_template_variable sooner, before (and regardless of) the
type_dependent_expression_p test.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/noexcept1.C: Don't expect a bogus "different
exception specifier" error. Expect a separate "not usable
in a constant expression" error.
* g++.dg/cpp1y/var-templ75.C: New test.
* g++.dg/cpp1y/var-templ76.C: New test.
This is a bug in tree-ssa-uninit.cc.
When doing the following:
/* Ignore the call to .DEFERRED_INIT that define the original
var itself as the following case:
temp = .DEFERRED_INIT (4, 2, “alt_reloc");
alt_reloc = temp;
In order to avoid generating warning for the fake usage
at alt_reloc = temp.
*/
We need to compare the var name inside the .DEFERRED_INIT call
(the 3rd argument) and the name for the LHS variable. if they are the same,
we will NOT report the warning.
There is one issue when we get the name for the LHS variable. when the
variable doesn't have a DECL_NAME (it's not a user declared variable,
which is the case for this bug):
_1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
D.2389 = _1;
The current checking just ignores this case, and still report the warning.
The fix is very simple, when getting the name for the LHS variable, we should
consider this case and come up with the name the same way as we construct the
3rd argument for the call to .DEFERRED_INIT (please refer to the routine
"gimple_add_init_for_auto_var")
PR middle-end/107411
gcc/ChangeLog:
PR middle-end/107411
* gimplify.cc (gimple_add_init_for_auto_var): Use sprintf to replace
xasprintf.
* tree-ssa-uninit.cc (warn_uninit): Handle the case when the
LHS varaible of a .DEFERRED_INIT call doesn't have a DECL_NAME.
gcc/testsuite/ChangeLog:
PR middle-end/107411
* g++.dg/pr107411.C: New test.
