testsuite: 'b' instruction can't do long enough jumps
After moving the testglue in commit 9d503515cee, the jump to exit and
abort is too far for the 'b' instruction on Cortex-M0. As most of the
C code would generate a 'bl' instruction instead of a 'b'
instruction, lets do the same for the inline assembler.
The error seen without this patch:
/tmp/cccCRiCl.o: in function `main':
stack-protector-1.c:(.text+0x4e): relocation truncated to fit: R_ARM_THM_JUMP11 against symbol `__wrap_exit' defined in .text section in gcc_tg.o
stack-protector-1.c:(.text+0x50): relocation truncated to fit: R_ARM_THM_JUMP11 against symbol `__wrap_abort' defined in .text section in gcc_tg.o
collect2: error: ld returned 1 exit status
gcc/testsuite/ChangeLog:
* gcc.target/arm/stack-protector-1.c: Use 'bl' instead of 'b'
instruction.
* gcc.target/arm/stack-protector-3.c: Likewise.
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is instead named "nul".
The error would look like this:
c:/arm-11.3.rel1/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: cannot find @/dev/null: No such file or directory
Patch has been verified on Windows and Linux.
gcc/testsuite:
* gcc.misc-tests/outputs.exp: Use "@nul" for Windows,
"@/dev/null" for other environments.
David Malcolm [Wed, 5 Oct 2022 00:19:07 +0000 (20:19 -0400)]
analyzer: revamp side-effects of call summaries [PR107072]
With -fanalyzer-call-summaries the analyzer canl attempt to summarize
the effects of some function calls at their call site, rather than
simulate the call directly, which can avoid big slowdowns during
analysis.
Previously, this summarization was extremely simplistic: no attempt
was made to update sm-state, and region_model::update_for_call_summary
would simply set the return value of the function to UNKNOWN, and assume
the function had no side effects.
This patch implements less simplistic summarizations: it tracks each
possible return enode from the called function, and attempts to generate
a successor enode from the callsite for each that have compatible
conditions, mapping state changes in the summary to state changes
at the callsite. It also implements the beginnings of heuristics for
generating user-facing descriptions of a summary e.g.
"when 'foo' returns NULL"
versus:
"when 'foo' returns a heap-allocated buffer"
This still has some bugs, but much more accurately tracks the effects
of a call, and so is an improvement; it should only have an effect
when -fanalyzer-call-summaries is enabled.
As before, -fanalyzer-call-summaries is disabled by default in
analyzer.opt (but enabled by default in the test suite).
gcc/analyzer/ChangeLog:
PR analyzer/107072
* analyzer-logging.h: Include "diagnostic-core.h".
* analyzer.h: Include "function.h".
(class call_summary): New forward decl.
(class call_summary_replay): New forward decl.
(struct per_function_data): New forward decl.
(struct interesting_t): New forward decl.
(custom_edge_info::update_state): New vfunc.
* call-info.cc (custom_edge_info::update_state): New.
* call-summary.cc: New file.
* call-summary.h: New file.
* constraint-manager.cc: Include "analyzer/call-summary.h".
(class replay_fact_visitor): New.
(constraint_manager::replay_call_summary): New.
* constraint-manager.h (constraint_manager::replay_call_summary):
New.
* engine.cc: Include "analyzer/call-summary.h".
(exploded_node::on_stmt): Handle call summaries.
(class call_summary_edge_info): New.
(exploded_node::replay_call_summaries): New.
(exploded_node::replay_call_summary): New.
(per_function_data::~per_function_data): New.
(per_function_data::add_call_summary): Move here from header and
reimplement.
(exploded_graph::process_node): Call update_state rather than
update_model when handling bifurcation
(viz_callgraph_node::dump_dot): Use a regular label rather
than an HTML table; add summaries to dump.
* exploded-graph.h: Include "alloc-pool.h", "fibonacci_heap.h",
"supergraph.h", "sbitmap.h", "shortest-paths.h", "analyzer/sm.h",
"analyzer/program-state.h", and "analyzer/diagnostic-manager.h".
(exploded_node::replay_call_summaries): New decl.
(exploded_node::replay_call_summary): New decl.
(per_function_data::~per_function_data): New decl.
(per_function_data::add_call_summary): Move implemention from
header.
(per_function_data::m_summaries): Update type of element.
* known-function-manager.h: Include "analyzer/analyzer-logging.h".
* program-point.h: Include "pretty-print.h" and
"analyzer/call-string.h".
* program-state.cc: Include "analyzer/call-summary.h".
(sm_state_map::replay_call_summary): New.
(program_state::replay_call_summary): New.
* program-state.h (sm_state_map::replay_call_summary): New decl.
(program_state::replay_call_summary): New decl.
* region-model-manager.cc
(region_model_manager::get_or_create_asm_output_svalue): New
overload.
* region-model-manager.h
(region_model_manager::get_or_create_asm_output_svalue): New
overload decl.
* region-model.cc: Include "analyzer/call-summary.h".
(region_model::maybe_update_for_edge): Remove call to
region_model::update_for_call_summary on
SUPEREDGE_INTRAPROCEDURAL_CALL.
(region_model::update_for_call_summary): Delete.
(region_model::replay_call_summary): New.
* region-model.h (region_model::replay_call_summary): New decl.
(region_model::update_for_call_summary): Delete decl.
* store.cc: Include "analyzer/call-summary.h".
(store::replay_call_summary): New.
(store::replay_call_summary_cluster): New.
* store.h: Include "tristate.h".
(is_a_helper <const ana::concrete_binding *>::test): New.
(store::replay_call_summary): New decl.
(store::replay_call_summary_cluster): New decl.
* supergraph.cc (get_ultimate_function_for_cgraph_edge): Remove
"static" from decl.
(supergraph_call_edge): Make stmt param const.
* supergraph.h: Include "ordered-hash-map.h", "cfg.h",
"basic-block.h", "gimple.h", "gimple-iterator.h", and "digraph.h".
(supergraph_call_edge): Make stmt param const.
(get_ultimate_function_for_cgraph_edge): New decl.
* svalue.cc (compound_svalue::compound_svalue): Assert that we're
not nesting compound_svalues.
* svalue.h: Include "json.h", "analyzer/store.h", and
"analyzer/program-point.h".
(asm_output_svalue::get_num_outputs): New accessor.
gcc/testsuite/ChangeLog:
PR analyzer/107072
* gcc.dg/analyzer/call-summaries-2.c: New test.
* gcc.dg/analyzer/call-summaries-3.c: New test.
* gcc.dg/analyzer/call-summaries-asm-x86.c: New test.
* gcc.dg/analyzer/call-summaries-malloc.c: New test.
* gcc.dg/analyzer/call-summaries-pr107072.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Wed, 5 Oct 2022 00:19:06 +0000 (20:19 -0400)]
analyzer: widening_svalues take a function_point rather than a program_point
Enabling work towrads better call summarization.
gcc/analyzer/ChangeLog:
* region-model-manager.cc
(region_model_manager::get_or_create_widening_svalue): Use a
function_point rather than a program_point.
* region-model.cc (selftest::test_widening_constraints): Likewise.
* region-model.h
(region_model_manager::get_or_create_widening_svalue): Likewise.
(model_merger::get_function_point): New.
* svalue.cc (svalue::can_merge_p): Use a function_point rather
than a program_point.
(svalue::can_merge_p): Likewise.
* svalue.h (widening_svalue::key_t): Likewise.
(widening_svalue::widening_svalue): Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Jason Merrill [Tue, 4 Oct 2022 21:06:04 +0000 (17:06 -0400)]
c++: fix debug info for array temporary [PR107154]
In the testcase the elaboration of the array init that happens at genericize
time was getting the location info for the end of the function; fixed by
doing the expansion at the location of the original expression.
PR c++/107154
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_genericize_init_expr): Use iloc_sentinel.
(cp_genericize_target_expr): Likewise.
Jakub Jelinek [Tue, 4 Oct 2022 21:13:15 +0000 (23:13 +0200)]
attribs: Add overloads with namespace name
I've discovered a problem with the way we handle scoped attributes. For
declaration or type attributes for attributes we don't know anything about
we just don't add them to the declarations or types, so later in the FEs and
middle-end it is fine to use lookup_attribute etc. which just check the
attribute name and not namespace because non-standard non-GNU attributes
just won't show there. But in the case of attributes on statements, nothing
has filtered out the unknown attributes, so with my earlier assume
attribute patch e.g. c-c++-common/Wno-attributes-6.c test failed because
it uses:
[[vendor::assume(1 + 1 == 2)]];
with -Wno-attributes=vendor::assume and lookup_attribute ("assume", )
finds such attribute and handled it that way.
So, for those cases, this patch introduces lookup_attribute and
remove_attribute overloads which specify also the namespace.
I think the fallthrough, hot, cold, likely, unlikely attribute handling
will need to use the new APIs too, so that we don't handle
msft::fallthrough attribute as something we'd know.
2022-10-04 Jakub Jelinek <jakub@redhat.com>
* attribs.h (remove_attribute): Declare overload with additional
attr_ns argument.
(private_lookup_attribute): Declare overload with additional
attr_ns and attr_ns_len arguments.
(lookup_attribute): New overload with additional attr_ns argument.
* attribs.cc (remove_attribute): New overload with additional
attr_ns argument.
(private_lookup_attribute): New overload with additional
attr_ns and attr_ns_len arguments.
Jakub Jelinek [Tue, 4 Oct 2022 19:05:16 +0000 (21:05 +0200)]
attribs: Add missing auto_diagnostic_group 3 times
In these spots, the error/error_at has some inform afterwards which are
explanation part of the same diagnostics, so should be tied with
auto_diagnostic_group with it.
2022-10-04 Jakub Jelinek <jakub@redhat.com>
* attribs.cc (handle_ignored_attributes_option, decl_attributes,
common_function_versions): Use auto_diagnostic_group.
Aldy Hernandez [Tue, 4 Oct 2022 17:50:28 +0000 (19:50 +0200)]
Remove assert from set_nonzero_bits.
The assert removed by this patch was there to keep users from passing
masks of incompatible types. The self tests are passing host wide
ints down (set_nonzero_bits (-1)), which seem to be 32 bits, whereas
some embedded targets have integer_type_node's of 16-bits. This is
causing problems in m32c-elf, among others.
I suppose there's no harm in passing a 32-bit mask, because
set_nonzero_bits calls wide_int::from() to convert the mask to the
appropriate type. So we can remove the assert.
Jonathan Wakely [Tue, 4 Oct 2022 12:00:52 +0000 (13:00 +0100)]
libstdc++: Use new built-ins __remove_cv, __remove_reference etc.
libstdc++-v3/ChangeLog:
* include/std/type_traits (remove_cv): Use __remove_cv built-in.
(remove_reference): Use __remove_reference built-in.
(remove_cvref): Use __remove_cvref built-in. Remove inheritance
for fallback implementation.
Jonathan Wakely [Tue, 4 Oct 2022 11:57:33 +0000 (12:57 +0100)]
libstdc++: Refactor seed sequence constraints in <random>
Every use of _If_seed_seq in <random> and <ext/random> uses it with
enable_if. We can just move the enable_if into the helper alias instead
of repeating it everywhere.
libstdc++-v3/ChangeLog:
* include/bits/random.h (__is_seed_seq): Replace with ...
(_If_seed_seq_for): ... this.
* include/ext/random: Adjust to use _If_seed_seq_for.
https://github.com/ARM-software/acle/pull/199 adds a new feature
macro for RCPC, for use in things like inline assembly. This patch
adds the associated support to GCC.
Also, RCPC is required for Armv8.3-A and later, but the armv8.3-a
entry didn't include it. This was probably harmless in practice
since GCC simply ignored the extension until now. (The GAS
definition is OK.)
gcc/
* config/aarch64/aarch64.h (AARCH64_ISA_RCPC): New macro.
* config/aarch64/aarch64-arches.def (armv8.3-a): Include RCPC.
* config/aarch64/aarch64-cores.def (thunderx3t110, zeus, neoverse-v1)
(neoverse-512tvb, saphira): Remove RCPC from these Armv8.3-A+ cores.
* config/aarch64/aarch64-c.cc (aarch64_update_cpp_builtins): Define
__ARM_FEATURE_RCPC when appropriate.
Jonathan Wakely [Tue, 4 Oct 2022 13:18:07 +0000 (14:18 +0100)]
libstdc++: Disable test for freestanding
This test checks the exception-safety of std::stable_sort if copying a
value throws. For freestanding we don't allocate in std::stable_sort
anyway, and the exception thrown via __throw_runtime_error terminates,
so disable the test.
libstdc++-v3/ChangeLog:
* testsuite/25_algorithms/stable_sort/mem_check.cc: Do nto run
for freestanding.
Jonathan Wakely [Mon, 3 Oct 2022 20:49:27 +0000 (21:49 +0100)]
libstdc++: Make <cstdint> work freestanding [PR107134]
When gcc/config.gcc defines use_gcc_stdin=wrap, GCC's <stdint.h> tries
to use libc's <stdint.h> unless -ffreestanding is used.
When libstdc++ is configured --disable-hosted-libstdcxx we want
<cstdint> to work even without -ffreestanding being given. This is a
kluge to make it include GCC's <stdint-gcc.h> directly even without
-ffreestanding.
libstdc++-v3/ChangeLog:
PR libstdc++/107134
* include/c_global/cstdint [!_GLIBCXX_HOSTED]: Include
<stdint-gcc.h> directly.
Jonathan Wakely [Mon, 3 Oct 2022 19:53:35 +0000 (20:53 +0100)]
libstdc++: Define <bits/functexcept.h> functions for freestanding [PR107135]
We don't compile src/c++11/functexcept.cc for freestanding, so just
define the functions used by freestanding entities as inline calls to
std::terminate.
Tobias Burnus [Tue, 4 Oct 2022 09:49:18 +0000 (11:49 +0200)]
install.texi: gcn - update llvm reqirements, gcn/nvptx - newlib use version
gcc/
* doc/install.texi (Specific): Add missing items to bullet list.
(amdgcn): Update LLVM requirements, use version not date for newlib.
(nvptx): Use version not git hash for newlib.
Arsen Arsenović [Sat, 1 Oct 2022 18:40:05 +0000 (20:40 +0200)]
libstdc++: Use ///< for inline documentation
I noticed that some variables were misdocumented when using trailing
comment for documentation. I ran a search with a relatively simple
regex[1] to look for any ///s following some code that did not have a <,
and came up with these instances only.
[1]: \s*([^ ]+\s*)+///[^<].*$
libstdc++-v3/ChangeLog:
* include/std/iostream: Use ///< for inline documentation.
* include/std/limits: Likewise.
* include/experimental/internet: Likewise.
Jakub Jelinek [Tue, 4 Oct 2022 08:37:14 +0000 (10:37 +0200)]
openmp: Add begin declare target support
The following patch adds support for the begin declare target construct,
which is another spelling for declare target construct without clauses
(where it needs paired end declare target), but unlike that one accepts
clauses.
This is an OpenMP 5.1 feature, implemented with 5.2 clarification because
in 5.1 we had a restriction in the declare target chapter shared by
declare target and begin declare target that if there are any clauses
specified at least one of them needs to be to or link. But that
was of course meant just for declare target and not begin declare target,
because begin declare target doesn't even allow to/link/enter clauses.
In addition to that, the patch also makes device_type clause duplication
an error (as stated in 5.1) and similarly makes declare target with
just device_type clause an error rather than warning.
What this patch doesn't do is:
1) OpenMP 5.1 also added an indirect clause, we don't support that
neither on declare target nor begin declare target
and I couldn't find it in our features pages (neither libgomp.texi
nor web)
2) I think device_type(nohost)/device_type(host) support can't work for
variables (in 5.0 it only talked about procedures so this could be
also thought as 5.1 feature that we should just add to the list
and implement)
3) I don't see any use of the "omp declare target nohost" attribute, so
I'm not sure if device_type(nohost) works at all
2022-10-04 Jakub Jelinek <jakub@redhat.com>
gcc/c-family/
* c-omp.cc (c_omp_directives): Uncomment begin declare target
entry.
gcc/c/
* c-lang.h (struct c_omp_declare_target_attr): New type.
(current_omp_declare_target_attribute): Change type from
int to vec<c_omp_declare_target_attr, va_gc> *.
* c-parser.cc (c_parser_translation_unit): Adjust for that change.
If last pushed directive was begin declare target, use different
wording and simplify format strings for easier translations.
(c_parser_omp_clause_device_type): Uncomment
check_no_duplicate_clause call.
(c_parser_omp_declare_target): Adjust for the
current_omp_declare_target_attribute type change, push { -1 }.
Use error_at rather than warning_at for declare target with
only device_type clauses.
(OMP_BEGIN_DECLARE_TARGET_CLAUSE_MASK): Define.
(c_parser_omp_begin): Add begin declare target support.
(c_parser_omp_end): Adjust for the
current_omp_declare_target_attribute type change, adjust
diagnostics wording and simplify format strings for easier
translations.
* c-decl.cc (current_omp_declare_target_attribute): Change type from
int to vec<c_omp_declare_target_attr, va_gc> *.
(c_decl_attributes): Adjust for the
current_omp_declare_target_attribute type change. If device_type
was present on begin declare target, add "omp declare target host"
and/or "omp declare target nohost" attributes.
gcc/cp/
* cp-tree.h (struct omp_declare_target_attr): Rename to ...
(cp_omp_declare_target_attr): ... this. Add device_type member.
(omp_begin_assumes_data): Rename to ...
(cp_omp_begin_assumes_data): ... this.
(struct saved_scope): Change types of omp_declare_target_attribute
and omp_begin_assumes.
* parser.cc (cp_parser_omp_clause_device_type): Uncomment
check_no_duplicate_clause call.
(cp_parser_omp_all_clauses): Fix up pasto, c_name for OMP_CLAUSE_LINK
should be "link" rather than "to".
(cp_parser_omp_declare_target): Adjust for omp_declare_target_attr
to cp_omp_declare_target_attr changes, push -1 as device_type. Use
error_at rather than warning_at for declare target with only
device_type clauses.
(OMP_BEGIN_DECLARE_TARGET_CLAUSE_MASK): Define.
(cp_parser_omp_begin): Add begin declare target support. Adjust
for omp_begin_assumes_data to cp_omp_begin_assumes_data change.
(cp_parser_omp_end): Adjust for the
omp_declare_target_attr to cp_omp_declare_target_attr and
omp_begin_assumes_data to cp_omp_begin_assumes_data type changes,
adjust diagnostics wording and simplify format strings for easier
translations.
* semantics.cc (finish_translation_unit): Likewise.
* decl2.cc (cplus_decl_attributes): If device_type was present on
begin declare target, add "omp declare target host" and/or
"omp declare target nohost" attributes.
gcc/testsuite/
* c-c++-common/gomp/declare-target-4.c: Move tests that are now
rejected into declare-target-7.c.
* c-c++-common/gomp/declare-target-6.c: Adjust expected diagnostics.
* c-c++-common/gomp/declare-target-7.c: New test.
* c-c++-common/gomp/begin-declare-target-1.c: New test.
* c-c++-common/gomp/begin-declare-target-2.c: New test.
* c-c++-common/gomp/begin-declare-target-3.c: New test.
* c-c++-common/gomp/begin-declare-target-4.c: New test.
* g++.dg/gomp/attrs-9.C: Add begin declare target tests.
* g++.dg/gomp/attrs-18.C: New test.
libgomp/
* libgomp.texi (Support begin/end declare target syntax in C/C++):
Mark as implemented.
Aldy Hernandez [Sat, 1 Oct 2022 20:49:32 +0000 (22:49 +0200)]
Convert nonzero mask in irange to wide_int.
The reason the nonzero mask was kept in a tree was basically inertia,
as everything in irange is a tree. However, there's no need to keep
it in a tree, as the conversions to and from wide ints are very
annoying. That, plus special casing NULL masks to be -1 is prone
to error.
I have not only rewritten all the uses to assume a wide int, but
have corrected a few places where we weren't propagating the masks, or
rather pessimizing them to -1. This will become more important in
upcoming patches where we make better use of the masks.
Performance testing shows a trivial improvement in VRP, as things like
irange::contains_p() are tied to a tree. Ughh, can't wait for trees in
iranges to go away.
gcc/ChangeLog:
* value-range-storage.cc (irange_storage_slot::set_irange): Remove
special case.
* value-range.cc (irange::irange_set): Adjust for nonzero mask
being a wide int.
(irange::irange_set_anti_range): Same.
(irange::set): Same.
(irange::verify_range): Same.
(irange::legacy_equal_p): Same.
(irange::operator==): Same.
(irange::contains_p): Same.
(irange::legacy_intersect): Same.
(irange::legacy_union): Same.
(irange::irange_single_pair_union): Call union_nonzero_bits.
(irange::irange_union): Same.
(irange::irange_intersect): Call intersect_nonzero_bits.
(irange::intersect): Adjust for nonzero mask being a wide int.
(irange::invert): Same.
(irange::set_nonzero_bits): Same.
(irange::get_nonzero_bits_from_range): New.
(irange::set_range_from_nonzero_bits): New.
(irange::get_nonzero_bits): Adjust for nonzero mask being a wide
int.
(irange::intersect_nonzero_bits): Same.
(irange::union_nonzero_bits): Same.
(range_tests_nonzero_bits): Remove test.
* value-range.h (irange::varying_compatible_p): Adjust for nonzero
mask being a wide int.
(gt_ggc_mx): Same.
(gt_pch_nx): Same.
(irange::set_undefined): Same.
(irange::set_varying): Same.
(irange::normalize_kind): Same.
Aldy Hernandez [Mon, 3 Oct 2022 15:31:32 +0000 (17:31 +0200)]
[PR107130] range-ops: Separate out ffs and popcount optimizations.
__builtin_popcount and __builtin_ffs were sharing the same range-ops
entry, but the nonzero mask optimization is not valid for ffs.
Separate them out into two entries.
PR tree-optimization/107130
gcc/ChangeLog:
* gimple-range-op.cc (class cfn_popcount): Call op_cfn_ffs.
(class cfn_ffs): New.
(gimple_range_op_handler::maybe_builtin_call): Separate out
CASE_CFN_FFS into its own case.
Jonathan Wakely [Fri, 30 Sep 2022 12:36:30 +0000 (13:36 +0100)]
libstdc++: Enable std::bitset<N>::bitset(const char*) for freestanding
The std::bitset constructor from a character string is specified in
terms of std::basic_string and std::char_traits, but doesn't need to be.
This makes it available for freestanding.
libstdc++-v3/ChangeLog:
* include/std/bitset (bitset(const C*, size_type n, C, C))
[!_GLIBCXX_HOSTED]: Remove std::basic_string dependency.
(_M_copy_from_ptr) [!_GLIBCXX_HOSTED]: Abort instead of
throwing.
libstdc++: Make some tests work on freestanding [PR103626]
PR libstdc++/103626 - _GLIBCXX_HOSTED should respect -ffreestanding
Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/103626
* testsuite/17_intro/headers/c++1998/stdc++.cc [!__STDC_HOSTED__]:
Do not include C headers that aren't valid for freestanding.
* testsuite/17_intro/tag_type_explicit_ctor.cc [!__STDC_HOSTED__]:
Do not test tag types that aren't defined for freestanding.
* testsuite/18_support/headers/cstdlib/functions_std.cc: Do not
check for std::getenv and std::system for freestanding.
* testsuite/17_intro/using_namespace_std_exp_neg.cc [!__STDC_HOSTED__]:
Do not test hosted parts of the standard library.
* testsuite/17_intro/using_namespace_std_tr1_neg.cc [!__STDC_HOSTED__]:
Likewise.
* testsuite/20_util/allocator_traits/members/rebind_alloc.cc [!__STDC_HOSTED__]:
Likewise.
* testsuite/20_util/allocator_traits/requirements/explicit_instantiation.cc [!HOSTED]:
Likewise.
* testsuite/20_util/headers/bitset/synopsis.cc [!__STDC_HOSTED__]: Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc [!__STDC_HOSTED__]:
Likewise.
* testsuite/20_util/pointer_traits/requirements/typedefs.cc [!__STDC_HOSTED__]:
Likewise.
* testsuite/20_util/tuple/cons/deduction.cc [!__STDC_HOSTED__]: Likewise.
* testsuite/25_algorithms/move/93872.cc [!__STDC_HOSTED__]: Likewise.
* testsuite/std/ranges/adaptors/100577.cc [!__STDC_HOSTED__]: Likewise.
libstdc++: Rework how freestanding install works [PR106953]
In light of there being far more freestanding headers now, ad-hoc
maintenance of a subset of the install implementation has become
unsustainable. Instead, we gate off a part of the normal install routine
so that it works without HOSTED enabled, as well as subdivide lists of
headers into freestanding and hosted components, according to the HOSTED
flag.
libstdc++-v3/ChangeLog:
PR libstdc++/106953
* include/Makefile.am [!_GLIBCXX_HOSTED]: Remove
install-freestanding-headers, unifying it with the usual
install-headers
* include/Makefile.in: Regenerate.
* include/precompiled/extc++.h [!_GLIBCXX_HOSTED]: Do not
include headers that aren't valid for freestanding.
* include/precompiled/stdc++.h [!_GLIBCXX_HOSTED]: Likewise.
libstdc++: Filter out unconditional <stdio.h> default include
_AC_INCLUDES_DEFAULT_REQUIREMENTS including <stdio.h> when checking for
stdint.h has prevented proper detection of whether stdint.h is present,
since it'd poison the cache variables with test results failing due to
<stdio.h> failing to include. As a solution, for autoconf versions under
2.70, we filter out that bit of code from ac_includes_default.
This issue was fixed in autoconf-2.70.
This also applies to various other headers, but was noticed when looking
into why HAVE_STDINT_H was misdefined.
libstdc++-v3/ChangeLog:
* configure.ac: Remove any lines that unconditionally include
<stdio.h> from ac_includes_default, when running Autoconf <2.70.
* configure: Regenerate.
Jonathan Wakely [Tue, 20 Sep 2022 10:57:28 +0000 (11:57 +0100)]
libstdc++: Make _GLIBCXX_HOSTED respect -ffreestanding [PR103626]
This allows the library to switch to freestanding mode when compiling
with the -ffreestanding flag. This means you don't need a separate
libstdc++ build configured with --disable-hosted-libstdcxx in order to
compile for a freestanding environment.
The testsuite support files cannot be compiled for freestanding, so add
-fno-freestanding to override any -ffreestanding in the test flags.
Andrew Stubbs [Fri, 2 Oct 2020 14:12:50 +0000 (15:12 +0100)]
vect: while_ult for integer masks
Add a vector length parameter needed by amdgcn without breaking aarch64.
All amdgcn vector masks are DImode, regardless of vector length, so we can't
tell what length is implied simply from the operator mode. (Even if we used
different integer modes there's no mode small enough to differenciate a 2 or
4 lane mask). Without knowing the intended length we end up using a mask with
too many lanes enabled, which leads to undefined behaviour..
The extra operand is not added for vector mask types so AArch64 does not need
to be adjusted.
gcc/ChangeLog:
* config/gcn/gcn-valu.md (while_ultsidi): Limit mask length using
operand 3.
* doc/md.texi (while_ult): Document new operand 3 usage.
* internal-fn.cc (expand_while_optab_fn): Set operand 3 when lhs_type
maps to a non-vector mode.
Christophe Lyon [Mon, 3 Oct 2022 10:26:03 +0000 (12:26 +0200)]
arm: Add missing early clobber to MVE vrev64q_m patterns
Like the non-predicated vrev64q patterns, mve_vrev64q_m_<supf><mode>
and mve_vrev64q_m_f<mode> need an early clobber constraint, otherwise
we can generate an unpredictable instruction:
Warning: 64-bit element size and same destination and source operands makes instruction UNPREDICTABLE
when calling vrevq64_m* with the same first and second arguments.
OK for trunk?
Thanks,
Christophe
gcc/ChangeLog:
* config/arm/mve.md (mve_vrev64q_m_<supf><mode>): Add early
clobber.
(mve_vrev64q_m_f<mode>): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/arm/mve/intrinsics/vrev64q_m_s16-clobber.c: New test.
Joseph Myers [Mon, 3 Oct 2022 13:10:42 +0000 (13:10 +0000)]
c: Adjust LDBL_EPSILON for C2x for IBM long double
C2x changes the <float.h> definition of *_EPSILON to apply only to
normalized numbers. The effect is that LDBL_EPSILON for IBM long
double becomes 0x1p-105L instead of 0x1p-1074L.
There is a reasonable case for considering this a defect fix - it
originated from the issue reporting process (DR#467), though it ended
up being resolved by a paper (N2326) for C2x rather than through the
issue process, and code using *_EPSILON often needs to override the
pre-C2x value of LDBL_EPSILON and use something on the order of
magnitude of the C2x value instead. However, I've followed the
conservative approach of only making the change for C2x and not for
previous standard versions (and not for C++, which doesn't have the
C2x changes in this area).
The testcases added are intended to be valid for all long double
formats. The C11 one is based on
gcc.target/powerpc/rs6000-ldouble-2.c (and when we move to a C2x
default, gcc.target/powerpc/rs6000-ldouble-2.c will need an
appropriate option added to keep using an older language version).
Tested with no regressions for cross to powerpc-linux-gnu.
gcc/c-family/
* c-cppbuiltin.cc (builtin_define_float_constants): Do not
special-case __*_EPSILON__ setting for IBM long double for C2x.
gcc/testsuite/
* gcc.dg/c11-float-7.c, gcc.dg/c2x-float-12.c: New tests.
Jonathan Wakely [Mon, 3 Oct 2022 11:10:07 +0000 (12:10 +0100)]
libstdc++: Fix tests broken by C++23 P2266R3 "Simpler implicit move"
In C++23 mode these tests started to FAIL because an rvalue reference
parameter can no longer be bound to an lvalue reference return type. As
confirmed by Ville (who added these tests) the problem overloads are not
intended to be called, and only exist to verify that they don't
interfere with the intended behaviour. This changes the function bodies
to just throw, so that the tests will fail if the function is called.
libstdc++-v3/ChangeLog:
* testsuite/27_io/basic_ostream/inserters_other/char/6.cc:
Change body of unused operator<< overload to throw if called.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/6.cc:
Likewise.
Aldy Hernandez [Sun, 2 Oct 2022 08:46:47 +0000 (10:46 +0200)]
Do not pessimize range in set_nonzero_bits.
Currently if we have a range of [0,0] and we set the nonzero bits to
1, the current code pessimizes the range to [0,1] because it assumes
the range is [1,1] plus the possibility of 0. This fixes the
oversight.
gcc/ChangeLog:
* value-range.cc (irange::set_nonzero_bits): Do not pessimize range.
(range_tests_nonzero_bits): New test.
François Dumont [Mon, 26 Sep 2022 17:14:54 +0000 (19:14 +0200)]
libstdc++: Fix gdb pretty printers when dealing with std::string
Since revision 33b43b0d8cd2de722d177ef823930500948a7487 std::string and other
similar typedef are ambiguous from a gdb point of view because it matches both
std::basic_string<char> and std::__cxx11::basic_string<char> symbols. For those
typedef add a workaround to accept the substitution as long as the same regardless
of __cxx11 namespace.
Also avoid to register printers for types in std::__cxx11::__8:: namespace, there is
no such symbols.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (Printer.add_version): Do not add version
namespace for __cxx11 symbols.
(add_one_template_type_printer): Likewise.
(add_one_type_printer): Likewise.
(FilteringTypePrinter._recognizer.recognize): Add a workaround for std::string & al
ambiguous typedef matching both std:: and std::__cxx11:: symbols.
* testsuite/libstdc++-prettyprinters/cxx17.cc: Remove obsolete
\#define _GLIBCXX_USE_CXX11_ABI 0.
* testsuite/libstdc++-prettyprinters/simple.cc: Likewise. Adapt test to accept
std::__cxx11::list.
* testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.
* testsuite/libstdc++-prettyprinters/whatis.cc: Likewise.
* testsuite/libstdc++-prettyprinters/80276.cc: Likewise and remove xfail for c++20
and debug mode.
* testsuite/libstdc++-prettyprinters/libfundts.cc: Likewise.
Olivier Hainque [Mon, 7 Mar 2022 10:55:29 +0000 (10:55 +0000)]
Adjust LIBGCC2_INCLUDES for VxWorks and augment comment
Investigating the reasons for libgcc build failures in a canadian
context, orthogonally to the recent update of vxcrtstuff, exposed
interesting differences in the way include search paths are managed
between a regular Linux->VxWorks cross build and a canadian setup
building a Windows->VxWorks toolchain in a Linux environment.
This change augments the comment attached to LIBGCC2_INCLUDE in
libgcc/config/t-vxworks to better describe the parameters at play.
It also adjusts the addition of options for gcc/include and
gcc/include-fixed to minimize the actual differences for libgcc
in the two kinds of configurations.
2022-03-06 Olivier Hainque <hainque@adacore.com>
libgcc/
* config/t-vxworks (LIBGCC2_INCLUDE): Augment comment. Move
-I options for gcc/include and gcc/include-fixed at the end
and make them -isystem.
Marc Poulhiès [Tue, 4 Jan 2022 14:56:27 +0000 (14:56 +0000)]
Define GCC_DRIVER_HOST_INITIALIZATION for VxWorks targets
We need to perform static links by default on VxWorks, where the use
of shared libraries involves unusual steps compared to standard native
systems.
This has to be conveyed before the lang_specific_driver code gets
invoked (in particular for g++), so specs aren't available.
This change defines the GCC_DRIVER_HOST_INITIALIZATION macro for
VxWorks, to insert a -static option in case the user hasn't provided any
explicit indication on the command line of the kind of link desired.
While a HOST macro doesn't seem appropriate to control a target OS
driven behavior, this matches other uses and won't conflict as VxWorks
is not supported on any of the other configurations using this macro.
But Wstrict-prototypes is internally registered as valid for
C/ObjC only, not C++, and this trick in turn triggers a Wpragma
warning with -Wsystem-headers.
This change just arranges to ignore the secondary warning locally.
2021-02-03 Olivier Hainque <hainque@adacore.com>
* config/gthr-vxworks.h: Prevent Wpragma warning for the
pragma diagnostics on Wstrict-prototypes.
Olivier Hainque [Thu, 10 Mar 2022 11:02:11 +0000 (11:02 +0000)]
Refine guard for vxworks crtstuff spec
Working on the reintroduction of shared libraries support
(and of modules depending on shared libraries) exposed a few
test failures of simple c++ constructor tests on arm-vxworks7r2.
Investigation revealed that we were not linking the
crtstuff objects as needed from a compiler configured not to
have shared libs support, because of the ENABLE_SHARED_LIBGCC
guard in this piece of vxworks.h:
/* Setup the crtstuff begin/end we might need for dwarf EH registration
and/or INITFINI_ARRAY support for shared libs. */
crtstuff initfini array support is meant to be leveraged for
constructors regardless of whether the compiler also happens to be
configured with shared library support, so the guard on ENABLE_SHARED_LIBGCC
here is inappropriate.
This change just removes it,
2022-09-30 Olivier Hainque <hainque@adacore.com>
gcc/
* config/vxworks.h (VX_CRTBEGIN_SPEC, VX_CRTEND_SPEC): If
HAVE_INITFINI_ARRAY_SUPPORT, pick crtstuff objects regardless
of ENABLE_SHARED_LIBGCC.
Fortran: Fix ICE and wrong code for assumed-rank arrays [PR100029, PR100040]
gcc/fortran/ChangeLog:
PR fortran/100040
PR fortran/100029
* trans-expr.cc (gfc_conv_class_to_class): Add code to have
assumed-rank arrays recognized as full arrays and fix the type
of the array assignment.
(gfc_conv_procedure_call): Change order of code blocks such that
the free of ALLOCATABLE dummy arguments with INTENT(OUT) occurs
first.
gcc/testsuite/ChangeLog:
PR fortran/100029
* gfortran.dg/PR100029.f90: New test.
PR fortran/100040
* gfortran.dg/PR100040.f90: New test.
Patrick Palka [Sat, 1 Oct 2022 16:21:36 +0000 (12:21 -0400)]
c++: make some cp_trait_kind switch statements exhaustive
This replaces the unreachable default case in some cp_trait_kind
switches with an exhaustive listing of the trait codes that we don't
expect to see, so that when adding a new trait we'll get a helpful
-Wswitch warning if we forget to handle the new trait in a relevant
switch.
or1k: Only define TARGET_HAVE_TLS when HAVE_AS_TLS
This was found when testing buildroot with linuxthreads enabled. In
this case, the build passes --disable-tls to the toolchain during
configuration. After building the OpenRISC toolchain it was still
generating TLS code sequences and causing linker failures such as:
Julian Brown [Fri, 30 Sep 2022 17:30:58 +0000 (17:30 +0000)]
OpenACC: Fix struct-component-kind-1.c test
This patch is a minimal fix for the recently-added
struct-component-kind-1.c test (which is currently failing to emit one
of the errors it expects in scan output). This fragment was erroneously
omitted from the second version of the patch posted previously:
Jeff Law [Sat, 1 Oct 2022 04:42:15 +0000 (00:42 -0400)]
Improve Z flag handling on H8
This patch improves handling of the Z bit in the status register in a
variety of ways to improve either the code size or code speed on various
H8 subtargets.
For example, we can test the zero/nonzero status of the upper byte of a
16 bit register using mov.b, we can move the Z or an inverted Z into a
QImode register profitably on some subtargets. We can move Z or an
inverted Z into the sign bit on the H8/SX profitably, etc.
Jason Merrill [Tue, 20 Sep 2022 20:06:26 +0000 (16:06 -0400)]
c++: loop through array CONSTRUCTOR
I noticed that we were ignoring all the special rules for when to use a
simple INIT_EXPR for array initialization from a CONSTRUCTOR, because
split_nonconstant_init_1 was also passing 1 to the from_array parameter.
Arguably that's the real bug, but I think we can be flexible.
The test that I noticed this with no longer fails without it.
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Clear from_array for CONSTRUCTOR
initializer.
Jeff Law [Fri, 30 Sep 2022 23:26:31 +0000 (19:26 -0400)]
More gimple const/copy propagation opportunities
While investigating a benchmark for optimization opportunities I came across single block loop which either iterates precisely once or forever. This is an interesting scenario as we can ignore the infinite looping path and treat any PHI nodes as degenerates. So more concretely let's consider this trivial testcase:
volatile void abort (void);
void
foo(int a)
{
int b = 0;
while (1)
{
if (!a)
break;
b = 1;
}
if (b != 0)
abort ();
}
Quick analysis shows that b's initial value is 0 and its value only changes if we enter an infinite loop. So if we get to the test b != 0, the only possible value b could have would be 0 and the test and its true arm can be eliminated.
This is a good representative of what the benchmark code looks like.
The primary effect we want to capture is to realize that the test if (b_1 != 0) is always false and optimize it accordingly.
In the benchmark, this opportunity is well hidden until after the loop optimizers have completed, so the first chance to capture this case is in DOM3. Furthermore, DOM wants loops normalized with latch blocks/edges. So instead of bb3 looping back to itself, there's an intermediate empty block during DOM.
I originally thought this was likely to only affect the benchmark. But when I instrumented the optimization and bootstrapped GCC, much to my surprise there were several hundred similar cases identified in GCC itself. So it's not as benchmark specific as I'd initially feared.
Anyway, detecting this in DOM is pretty simple. We detect the infinite loop, including the latch block. Once we've done that, we walk the PHI nodes and attach equivalences to the appropriate outgoing edge. That's all we need to do as the rest of DOM is already prepared to handle equivalences on edges.
gcc/
* tree-ssa-dom.cc (single_block_loop_p): New function.
(record_edge_info): Also record equivalences for the outgoing
edge of a single block loop where the condition is an invariant.
gcc/testsuite/
* gcc.dg/infinite-loop.c: New test.
Jeff Law [Fri, 30 Sep 2022 22:59:24 +0000 (18:59 -0400)]
Minor cleanup/prep in DOM
It's a bit weird that free_dom_edge_info leaves a dangling pointer in e->aux.
Not sure what I was thinking.
There's two callers. One wipes e->aux immediately after the call, the other
attaches a newly created object immediately after the call. So we can wipe
e->aux within the call and simplify one of the two call sites.
This is preparatory work for a minor optimization where we want to detect
another class of edge equivalences in DOM (until something better is available)
and either attach them an existing edge_info structure or create a new one if
one doesn't currently exist for a given edge.
gcc/
* tree-ssa-dom.cc (free_dom_edge_info): Clear e->aux too.
(free_all_edge_infos): Do not clear e->aux here.
This fixes f19a327077e ("Support -fexcess-precision=16 which will enable
FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 when backend supports _Float16.") on
RISC-V targets.
gcc/ChangeLog
PR target/106815
* config/riscv/riscv.cc (riscv_excess_precision): Add support
for EXCESS_PRECISION_TYPE_FLOAT16.
Jonathan Wakely [Fri, 30 Sep 2022 16:06:15 +0000 (17:06 +0100)]
libstdc++: Optimize operator>> for std::bitset
We can improve performance by using a char buffer instead of
basic_string. The loop bound already means we can't overflow the buffer,
and we don't need to keep writing a null character after every character
written to the buffer.
We could just use basic_string::resize(N) to zero-init the whole string,
then overwrite those chars. But that zero-init of all N chars would be
wasted in the case where we are writing to a bitset<N> with large N, but
only end up extracting one or two chars from the stream.
With this change we just use buffer of uninitialized chars. For a
small-ish bitset (currently <= 256) we can improve performance further
by using alloca instead of the heap.
libstdc++-v3/ChangeLog:
* include/std/bitset (operator>>): Use a simple buffer instead
of std::basic_string.
Jonathan Wakely [Fri, 30 Sep 2022 13:57:24 +0000 (14:57 +0100)]
libstdc++: Remove non-standard public members in std::bitset
This makes _M_copy_from_ptr, _M_copy_from_string and _M_copy_to_string
private, and declares operator<< and operator>> as friends.
Also remove the historical _M_copy_from_string and _M_copy_to_string
overloads. Those were used before DR 396 was implemented but are
not needed now. There are no tests or docs describing them, so I don't
think we intend to support them as extensions.
Jonathan Wakely [Fri, 30 Sep 2022 18:10:29 +0000 (19:10 +0100)]
libstdc++: Fix broken dg-prune-output
The new pattern in the dg-prune-output directive doesn't work. Instead
of a messy regex full of leaning toothpicks, just match on the
diagnostic text instead of the header paths.
Jakub Jelinek [Fri, 30 Sep 2022 19:54:08 +0000 (21:54 +0200)]
arm, csky: Fix C++ ICEs with _Float16 and __fp16 [PR107080]
On Fri, Sep 30, 2022 at 09:54:49AM -0400, Jason Merrill wrote:
> > Note, there is one further problem on aarch64/arm, types with HFmode
> > (_Float16 and __fp16) are there mangled as Dh (which is standard
> > Itanium mangling:
> > ::= Dh # IEEE 754r half-precision floating point (16 bits)
> > ::= DF <number> _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits)
> > so in theory is also ok, but DF16_ is more specific. Should we just
> > change Dh to DF16_ in those backends, or should __fp16 there be distinct
> > type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ?
>
> You argued for keeping __float128 separate from _Float128, does the same
> argument not apply to this case?
Actually, they already were distinct types that just mangled the same.
So the same issue that had to be solved on i?86, ia64 and rs6000 for
_Float64x vs. long double is a problem on arm and aarch64 with _Float16
vs. __fp16.
The following patch fixes it for arm after aarch64 has been changed
already before.
> > And there is csky, which mangles __fp16 (but only if type's name is __fp16,
> > not _Float16) as __fp16, that looks clearly invalid to me as it isn't
> > valid in the mangling grammar. So perhaps just nuke csky's mangle_type
> > and have it mangled as DF16_ by the generic code?
And seems even on csky __fp16 is distinct type from _Float16 (which is a
good thing for consistency, these 3 targets are the only ones that have
__fp16 type), so instead the patch handles it the same as on arm/aarch64,
Dh mangling for __fp16 and DF16_ for _Float16.
2022-09-30 Jakub Jelinek <jakub@redhat.com>
PR c++/107080
* config/arm/arm.cc (arm_mangle_type): Mangle just __fp16 as Dh
and _Float16 as DF16_.
* config/csky/csky.cc (csky_init_builtins): Fix a comment typo.
(csky_mangle_type): Mangle __fp16 as Dh and _Float16 as DF16_
rather than mangling __fp16 as __fp16.
Lewis Hyatt [Fri, 30 Sep 2022 18:10:00 +0000 (14:10 -0400)]
diagnostics: Fix virtual location for -Wuninitialized [PR69543]
Warnings issued for -Wuninitialized have been using the spelling location of
the problematic usage, discarding any information on the location of the macro
expansion point if such usage was in a macro. This makes the warnings
impossible to control reliably with #pragma GCC diagnostic, and also discards
useful context in the diagnostic output. There seems to be no need to discard
the virtual location information, so this patch fixes that.
PR69543 was mostly about _Pragma issues which have been fixed for many years
now. The PR remains open because two of the testcases added in response to it
still have xfails, but those xfails have nothing to do with _Pragma and rather
just with the issue fixed by this patch, so the PR can be closed now as well.
The other testcase modified here, pragma-diagnostic-2.c, was explicitly
testing for the undesirable behavior that was xfailed in pr69543-3.c. I have
adjusted that and also added a new testcase verifying all 3 types of warning
that come from tree-ssa-uninit.cc get the proper location information now.
gcc/ChangeLog:
PR preprocessor/69543
* tree-ssa-uninit.cc (warn_uninit): Stop stripping macro tracking
information away from the diagnostic location.
(maybe_warn_read_write_only): Likewise.
(maybe_warn_operand): Likewise.
gcc/testsuite/ChangeLog:
PR preprocessor/69543
* c-c++-common/pr69543-3.c: Remove xfail.
* c-c++-common/pr69543-4.c: Likewise.
* gcc.dg/cpp/pragma-diagnostic-2.c: Adjust test for new behavior.
* c-c++-common/pragma-diag-16.c: New test.
Jakub Jelinek [Fri, 30 Sep 2022 17:52:49 +0000 (19:52 +0200)]
aarch64: Fix C++ ICEs with _Float16 and __fp16 [PR107080]
On Fri, Sep 30, 2022 at 09:54:49AM -0400, Jason Merrill wrote:
> > Note, there is one further problem on aarch64/arm, types with HFmode
> > (_Float16 and __fp16) are there mangled as Dh (which is standard
> > Itanium mangling:
> > ::= Dh # IEEE 754r half-precision floating point (16 bits)
> > ::= DF <number> _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits)
> > so in theory is also ok, but DF16_ is more specific. Should we just
> > change Dh to DF16_ in those backends, or should __fp16 there be distinct
> > type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ?
>
> You argued for keeping __float128 separate from _Float128, does the same
> argument not apply to this case?
Actually, they already were distinct types that just mangled the same.
So the same issue that had to be solved on i?86, ia64 and rs6000 for
_Float64x vs. long double is a problem on arm and aarch64 with _Float16
vs. __fp16.
The following patch fixes it so far for aarch64.
2022-09-30 Jakub Jelinek <jakub@redhat.com>
PR c++/107080
* config/aarch64/aarch64.cc (aarch64_mangle_type): Mangle just __fp16
as Dh and _Float16 as DF16_.
Jakub Jelinek [Fri, 30 Sep 2022 16:40:35 +0000 (18:40 +0200)]
i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080]
The following testcase ICEs on x86 as well as ppc64le (the latter
with -mabi=ieeelongdouble), because _Float64x there isn't mangled as
DF64x but e or u9__ieee128 instead.
Those are the mangling that should be used for the non-standard
types with the same mode or for long double, but not for _Float64x.
All the 4 mangle_type targhook implementations start with
type = TYPE_MAIN_VARIANT (type);
so I think it is cleanest to handle it the same in all and return NULL
before the switches on mode or whatever other tests.
s390 doesn't actually have a bug, but while I was there, having
type = TYPE_MAIN_VARIANT (type);
if (TYPE_MAIN_VARIANT (type) == long_double_type_node)
looked useless to me.
Note, there is one further problem on aarch64/arm, types with HFmode
(_Float16 and __fp16) are there mangled as Dh (which is standard
Itanium mangling:
::= Dh # IEEE 754r half-precision floating point (16 bits)
::= DF <number> _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits)
so in theory is also ok, but DF16_ is more specific. Should we just
change Dh to DF16_ in those backends, or should __fp16 there be distinct
type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ?
And there is csky, which mangles __fp16 (but only if type's name is __fp16,
not _Float16) as __fp16, that looks clearly invalid to me as it isn't
valid in the mangling grammar. So perhaps just nuke csky's mangle_type
and have it mangled as DF16_ by the generic code?
2022-09-30 Jakub Jelinek <jakub@redhat.com>
PR c++/107080
* config/i386/i386.cc (ix86_mangle_type): Always return NULL
for float128_type_node or float64x_type_node, don't check
float128t_type_node later on.
* config/ia64/ia64.cc (ia64_mangle_type): Always return NULL
for float128_type_node or float64x_type_node.
* config/rs6000/rs6000.cc (rs6000_mangle_type): Likewise.
Don't check float128_type_node later on.
* config/s390/s390.cc (s390_mangle_type): Don't use
TYPE_MAIN_VARIANT on type which was set to TYPE_MAIN_VARIANT
a few lines earlier.
Checking that the triplet matches arm*-*-eabi (or msp430-*-*) is not
enough to know if the execution will enter an endless loop, or if it
will give a meaningful result. As the execution test only work when
VMA and LMA are equal, make sure that this condition is met.
gcc/ChangeLog:
* doc/sourcebuild.texi: Document new vma_equals_lma effective
target check.
Patrick Palka [Fri, 30 Sep 2022 15:06:54 +0000 (11:06 -0400)]
c++: streamline built-in trait addition process
Adding a new built-in trait currently involves manual boilerplate
consisting of defining an rid enumerator for the identifier as well as a
corresponding cp_trait_kind enumerator and handling them in various switch
statements, the exact set of which depends on whether the proposed trait
yields (and thus is recognized as) a type or an expression.
To streamline the process, this patch adds a central cp-trait.def file
that tabulates the essential details about each built-in trait (whether
it yields a type or an expression, its code, its spelling and its arity)
and uses this file to automate away the manual boilerplate. It also
migrates all the existing C++-specific built-in traits to use this
approach.
After this change, adding a new built-in trait just entails declaring
it in cp-trait.def and defining its behavior in finish_trait_expr/type
(and handling it in diagnose_trait_expr, if it's an expression-yielding
trait).
gcc/c-family/ChangeLog:
* c-common.cc (c_common_reswords): Use cp/cp-trait.def to handle
C++ traits.
* c-common.h (enum rid): Likewise.
Without this patch, the test case failes with:
.../ben-1_a.C:4:8: error: failed to write compiled module: Invalid argument
.../ben-1_a.C:4:8: note: compiled module file is 'partitions/module:import.mod'
gcc/testsuite:
* g++.dg/modules/ben-1.map: Replace the colon with dash.
* g++.dg/modules/ben-1_a.C: Likewise
Kewen Lin [Fri, 30 Sep 2022 12:16:49 +0000 (07:16 -0500)]
rs6000: Rework ELFv2 support for -fpatchable-function-entry* [PR99888]
As PR99888 and its related show, the current support for
-fpatchable-function-entry on powerpc ELFv2 doesn't work
well with global entry existence. For example, with one
command line option -fpatchable-function-entry=3,2, it got
below w/o this patch:
* doc/invoke.texi (option -fpatchable-function-entry): Adjust the
documentation for PowerPC ELFv2 ABI dual entry points.
* config/rs6000/rs6000-internal.h
(rs6000_print_patchable_function_entry): New function declaration.
* config/rs6000/rs6000-logue.cc (rs6000_output_function_prologue):
Support patchable-function-entry by emitting nops before and after
local entry for the function that needs global entry.
* config/rs6000/rs6000.cc (rs6000_print_patchable_function_entry): Skip
the function that needs global entry till global entry has been
emitted.
* config/rs6000/rs6000.h (struct machine_function): New bool member
global_entry_emitted.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr99888-1.c: New test.
* gcc.target/powerpc/pr99888-2.c: New test.
* gcc.target/powerpc/pr99888-3.c: New test.
* gcc.target/powerpc/pr99888-4.c: New test.
* gcc.target/powerpc/pr99888-5.c: New test.
* gcc.target/powerpc/pr99888-6.c: New test.
* c-c++-common/patchable_function_entry-default.c: Adjust for
powerpc_elfv2 to avoid compilation error.
Kewen Lin [Fri, 30 Sep 2022 12:16:36 +0000 (07:16 -0500)]
rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516]
As PR106516 shows, we can get unexpected gimple outputs for
function thud on some target which supports modulus operation
for vector int. This patch introduces one effective target
vect_int_mod for it, then adjusts the test case with it.
PR testsuite/106516
gcc/testsuite/ChangeLog:
* gcc.dg/pr104992.c: Adjust with vect_int_mod.
* lib/target-supports.exp (check_effective_target_vect_int_mod): New
effective target.
projects / thirdparty / gcc.git / log
