Previously, if a back end was not 'USE_COLLECT2', nor manually defined
'TARGET_ASM_CONSTRUCTOR', 'TARGET_ASM_DESTRUCTOR', or got pointed to the
respective 'default_[...]' functions due to 'CTORS_SECTION_ASM_OP',
'DTORS_SECTION_ASM_OP', or 'TARGET_ASM_NAMED_SECTION', it got pointed to
'default_stabs_asm_out_constructor', 'default_stabs_asm_out_destructor'.
These would emit 'sorry' for any global constructor/destructor they're
run into.
This is now gone, and thus in such a back end configuration case
'TARGET_ASM_CONSTRUCTOR', 'TARGET_ASM_DESTRUCTOR' don't get defined
anymore, and thus the subsequently following:
... simply does nothing anymore for a 'DECL_STATIC_CONSTRUCTOR',
'DECL_STATIC_DESTRUCTOR'.
This, effectively, means that GCC/nvptx now suddenly appears to "support"
global constructors/destructors, which means that a ton of test cases now
erroneously PASS that previously used to FAIL:
sorry, unimplemented: global constructors not supported on this target
Of course, such support didn't magically happen due to
"STABS: remove -gstabs and -gxcoff functionality", so this is bad. And,
corresponding execution testing then regularly FAILs (due to the global
constructor/destructor functions never being invoked), for example:
[-UNSUPPORTED:-]{+PASS:+} gcc.dg/initpri1.c {+(test for excess errors)+}
{+FAIL: gcc.dg/initpri1.c execution test+}
[-UNSUPPORTED:-]{+PASS:+} g++.dg/special/conpr-1.C {+(test for excess errors)+}
{+FAIL: g++.dg/special/conpr-1.C execution test+}
To restore the previous GCC/nvptx behavior, for traceability, this simply
restores the previous code, stripped down to the bare minimum.
arm: Allow to override location of .gnu.sgstubs section
Depending on the DejaGNU board definition, the .gnu.sgstubs section
might be placed on different locations in order to suit the target.
With this patch, the start location of the section is overrideable
from the board definition with the fallback of the previously
hardcoded location.
Marek Polacek [Tue, 1 Nov 2022 21:05:52 +0000 (17:05 -0400)]
c++: Quash -Wdangling-reference for member operator* [PR107488]
-Wdangling-reference complains here:
std::vector<int> v = ...;
std::vector<int>::const_iterator it = v.begin();
while (it != v.end()) {
const int &r = *it++; // warning
}
because it sees a call to
__gnu_cxx::__normal_iterator<const int*, std::vector<int> >::operator*
which returns a reference and its argument is a TARGET_EXPR representing
the result of
__gnu_cxx::__normal_iterator<const int*, std::vector<int> >::operator++
But 'r' above refers to one of the int elements of the vector 'v', not
to a temporary object. Therefore the warning is a false positive.
I suppose code like the above is relatively common (the warning broke
cppunit-1.15.1 and a few other projects), so presumably it makes sense
to suppress the warning when it comes to member operator*. In this case
it's defined as
and I'm guessing a lot of member operator* are like that, at least when
it comes to iterators. I've looked at _Fwd_list_iterator,
_Fwd_list_const_iterator, __shared_ptr_access, _Deque_iterator,
istream_iterator, etc, and they're all like that, so adding #pragmas
would be quite tedious. :/
PR c++/107488
gcc/cp/ChangeLog:
* call.cc (do_warn_dangling_reference): Quash -Wdangling-reference
for member operator*.
Patrick Palka [Thu, 3 Nov 2022 19:35:18 +0000 (15:35 -0400)]
c++: requires-expr and access checking [PR107179]
Like during satisfaction, we also need to avoid deferring access checks
during substitution of a requires-expr because the outcome of an access
check can determine the value of the requires-expr. Otherwise (in
deferred access checking contexts such as within a base-clause), the
requires-expr may evaluate to the wrong result, and along the way a
failed access check may leak out from it into a non-SFINAE context and
cause a hard error (as in the below testcase).
PR c++/107179
gcc/cp/ChangeLog:
* constraint.cc (tsubst_requires_expr): Make sure we're not
deferring access checks.
Jason Merrill [Thu, 3 Nov 2022 14:51:40 +0000 (10:51 -0400)]
c++: change -fconcepts to mean C++20 concepts
It was always weird that -fconcepts in C++17 mode meant the same thing as
-fconcepts-ts in C++20 mode; this patch harmonizes the flags so that for TS
concepts you always need to write -fconcepts-ts.
In the unlikely event anyone is still using -fconcepts in C++17 mode, they
can either fix their code to work with C++20 concepts or adjust the compiler
flag.
gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): -fconcepts no longer implies
-fconcepts-ts before C++20.
gcc/ChangeLog:
* doc/invoke.texi: -fconcepts no longer implies
-fconcepts-ts before C++20.
Patrick Palka [Thu, 3 Nov 2022 18:55:35 +0000 (14:55 -0400)]
c++: constexpr error with defaulted virtual dtor [PR93413]
We're rejecting the below testcase with
error: 'virtual constexpr Base::~Base()' used before its definition
error: 'virtual constexpr Derived::~Derived()' used before its definition
due to special handling in mark_used added by r181272 to defer synthesis
of virtual destructors until EOF (where we can set their linkage), which
in turn makes them effectively unusable during constexpr evaluation.
Fortunately it seems this special handling is unnecessary ever since
r208030 enabled us to tentatively set linkage of all defaulted virtual
destructors, including templated ones. So this patch gets rid of this
special handling.
PR c++/93413
gcc/cp/ChangeLog:
* decl2.cc (mark_used): Don't defer synthesis of virtual
functions.
amdgcn: Fix instruction generation for exp2 and log2 operations
The GCN instructions for the exp2 and log2 operations are v_exp_* and v_log_*
respectively, which unfortunately do not line up with the RTL naming
convention. To deal with this, a new set of int attributes is now used when
generating the assembly for these instructions.
David Malcolm [Thu, 3 Nov 2022 17:47:02 +0000 (13:47 -0400)]
analyzer: use std::unique_ptr for known functions
gcc/analyzer/ChangeLog:
* analyzer.h: Use std::unique_ptr for known functions.
* engine.cc: Likewise.
* known-function-manager.cc: Likewise.
* known-function-manager.h: Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/plugin/analyzer_kernel_plugin.c: Use std::unique_ptr for
known functions.
* gcc.dg/plugin/analyzer_known_fns_plugin.c: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Thu, 3 Nov 2022 17:47:02 +0000 (13:47 -0400)]
analyzer: use std::unique_ptr during bifurcation
gcc/analyzer/ChangeLog:
* analysis-plan.cc: Define INCLUDE_MEMORY before including
system.h.
* analyzer-pass.cc: Likewise.
* analyzer-selftests.cc: Likewise.
* analyzer.cc: Likewise.
* analyzer.h: Use std::unique_ptr in bifurcation code.
* call-string.cc: Define INCLUDE_MEMORY before including system.h.
* complexity.cc: Likewise.
* engine.cc: Use std::unique_ptr in bifurcation code.
* exploded-graph.h: Likewise.
* known-function-manager.cc: Define INCLUDE_MEMORY before
including system.h.
* region-model-impl-calls.cc: Use std::unique_ptr in bifurcation
code.
* region-model.cc: Likewise.
* region-model.h: Likewise.
* supergraph.cc: Define INCLUDE_MEMORY before including system.h.
gcc/testsuite/ChangeLog:
* gcc.dg/plugin/analyzer_kernel_plugin.c: Include "make-unique.h".
Use std::unique_ptr in bifurcation code.
* gcc.dg/plugin/analyzer_known_fns_plugin.c: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Thu, 3 Nov 2022 17:47:01 +0000 (13:47 -0400)]
analyzer: use std::unique_ptr for pending_diagnostic/note
gcc/analyzer/ChangeLog:
* call-info.cc: Add define of INCLUDE_MEMORY.
* call-summary.cc: Likewise.
* checker-path.cc: Likewise.
* constraint-manager.cc: Likewise.
* diagnostic-manager.cc: Likewise.
(saved_diagnostic::saved_diagnostic): Use std::unique_ptr for
param d and field m_d.
(saved_diagnostic::~saved_diagnostic): Remove explicit delete of m_d.
(saved_diagnostic::add_note): Use std::unique_ptr for
param pn.
(saved_diagnostic::get_pending_diagnostic): Update for conversion
of m_sd.m_d to unique_ptr.
(diagnostic_manager::add_diagnostic): Use std::unique_ptr for
param d. Remove explicit deletion.
(diagnostic_manager::add_note): Use std::unique_ptr for param pn.
(diagnostic_manager::emit_saved_diagnostic): Update for conversion
of m_sd.m_d to unique_ptr.
(null_assignment_sm_context::warn): Use std::unique_ptr for
param d. Remove explicit deletion.
* diagnostic-manager.h (saved_diagnostic::saved_diagnostic): Use
std::unique_ptr for param d.
(saved_diagnostic::add_note): Likewise for param pn.
(saved_diagnostic::m_d): Likewise.
(diagnostic_manager::add_diagnostic): Use std::unique_ptr for
param d.
(diagnostic_manager::add_note): Use std::unique_ptr for param pn.
* engine.cc: Include "make-unique.h".
(impl_region_model_context::warn): Update to use std::unique_ptr
for param, removing explicit deletion.
(impl_region_model_context::add_note): Likewise.
(impl_sm_context::warn): Update to use std::unique_ptr
for param.
(impl_region_model_context::on_state_leak): Likewise for result of
on_leak.
(exploded_node::on_longjmp): Use make_unique when creating
pending_diagnostic.
(exploded_graph::process_node): Likewise.
* exploded-graph.h (impl_region_model_context::warn): Update to
use std::unique_ptr for param.
(impl_region_model_context::add_note): Likewise.
* feasible-graph.cc: Add define of INCLUDE_MEMORY.
* pending-diagnostic.cc: Likewise.
* pending-diagnostic.h: Include analyzer.sm.h"
* program-point.cc: Add define of INCLUDE_MEMORY.
* program-state.cc: Likewise.
* region-model-asm.cc: Likewise.
* region-model-impl-calls.cc: Likewise. Include "make-unique.h".
(region_model::impl_call_putenv): Use make_unique when creating
pending_diagnostic.
* region-model-manager.cc: Add define of INCLUDE_MEMORY.
* region-model-reachability.cc: Likewise.
* region-model.cc: Likewise. Include "make-unique.h".
(region_model::get_gassign_result): Use make_unique when creating
pending_diagnostic.
(region_model::check_for_poison): Likewise.
(region_model::on_stmt_pre): Likewise.
(region_model::check_symbolic_bounds): Likewise.
(region_model::check_region_bounds): Likewise.
(annotating_ctxt: make_note): Use std::unique_ptr for result.
(region_model::deref_rvalue): Use make_unique when creating
pending_diagnostic.
(region_model::check_for_writable_region): Likewise.
(region_model::check_region_size): Likewise.
(region_model::check_dynamic_size_for_floats): Likewise.
(region_model::maybe_complain_about_infoleak): Likewise.
(noop_region_model_context::add_note): Use std::unique_ptr for
param. Remove explicit deletion.
* region-model.h: Include "analyzer/pending-diagnostic.h".
(region_model_context::warn): Convert param to std::unique_ptr.
(region_model_context::add_note): Likewise.
(noop_region_model_context::warn): Likewise.
(noop_region_model_context::add_note): Likewise.
(region_model_context_decorator::warn): Likewise.
(region_model_context_decorator::add_note): Likewise.
(note_adding_context::warn): Likewise.
(note_adding_context::make_note): Likewise for return type.
(test_region_model_context::warn): Convert param to
std::unique_ptr.
* region.cc: Add define of INCLUDE_MEMORY.
* sm-fd.cc: Likewise. Include "make-unique.h".
(fd_state_machine::check_for_fd_attrs): Use make_unique when
creating pending_diagnostics.
(fd_state_machine::on_open): Likewise.
(fd_state_machine::on_creat): Likewise.
(fd_state_machine::check_for_dup): Likewise.
(fd_state_machine::on_close): Likewise.
(fd_state_machine::check_for_open_fd): Likewise.
(fd_state_machine::on_leak): Likewise, converting return type to
std::unique_ptr.
* sm-file.cc: Add define of INCLUDE_MEMORY. Include
"make-unique.h".
(fileptr_state_machine::on_stmt): Use make_unique when creating
pending_diagnostic.
(fileptr_state_machine::on_leak): Likewise, converting return type
to std::unique_ptr.
* sm-malloc.cc: Add define of INCLUDE_MEMORY. Include
"make-unique.h".
(malloc_state_machine::on_stmt): Use make_unique when creating
pending_diagnostic.
(malloc_state_machine::handle_free_of_non_heap): Likewise.
(malloc_state_machine::on_deallocator_call): Likewise.
(malloc_state_machine::on_realloc_call): Likewise.
(malloc_state_machine::on_leak): Likewise, converting return type
to std::unique_ptr.
* sm-pattern-test.cc: Add define of INCLUDE_MEMORY. Include
"make-unique.h".
(pattern_test_state_machine::on_condition): Use make_unique when
creating pending_diagnostic.
* sm-sensitive.cc: Add define of INCLUDE_MEMORY. Include
"make-unique.h".
(sensitive_state_machine::warn_for_any_exposure): Use make_unique
when creating pending_diagnostic.
* sm-signal.cc: Add define of INCLUDE_MEMORY. Include
"make-unique.h".
(signal_state_machine::on_stmt): Use make_unique when creating
pending_diagnostic.
* sm-taint.cc: Add define of INCLUDE_MEMORY. Include
"make-unique.h".
(taint_state_machine::check_for_tainted_size_arg): Use make_unique
when creating pending_diagnostic.
(taint_state_machine::check_for_tainted_divisor): Likewise.
(region_model::check_region_for_taint): Likewise.
(region_model::check_dynamic_size_for_taint): Likewise.
* sm.cc: Add define of INCLUDE_MEMORY. Include
"analyzer/pending-diagnostic.h".
(state_machine::on_leak): Move here from sm.h, changing return
type to std::unique_ptr.
* sm.h (state_machine::on_leak): Change return type to
std::unique_ptr. Move defn of base impl to sm.cc
(sm_context::warn): Convert param d to std_unique_ptr.
* state-purge.cc: Add define of INCLUDE_MEMORY.
* store.cc: Likewise.
* svalue.cc: Likewise.
* trimmed-graph.cc: Likewise.
* varargs.cc: Likewise. Include "make-unique.h".
(va_list_state_machine::check_for_ended_va_list): Use make_unique
when creating pending_diagnostic.
(va_list_state_machine::on_leak): Likewise, converting return type
to std::unique_ptr.
(region_model::impl_call_va_arg): Use make_unique when creating
pending_diagnostic.
gcc/testsuite/ChangeLog:
* gcc.dg/plugin/analyzer_gil_plugin.c: Add define of
INCLUDE_MEMORY. Include "make-unique.h".
(gil_state_machine::check_for_pyobject_in_call): Use make_unique
when creating pending_diagnostic.
(gil_state_machine::on_stmt): Likewise.
(gil_state_machine::check_for_pyobject_usage_without_gil): Likewise.
* gcc.dg/plugin/analyzer_kernel_plugin.c: : Add define of
INCLUDE_MEMORY.
* gcc.dg/plugin/analyzer_known_fns_plugin.c: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Tobias Burnus [Thu, 3 Nov 2022 14:03:52 +0000 (15:03 +0100)]
OpenMP/Fortran: 'target update' with DT components
OpenMP 5.0 permits to use arrays with derived type components for the list
items to the 'from'/'to' clauses of the 'target update' directive.
gcc/fortran/ChangeLog:
* openmp.cc (gfc_match_omp_clauses): Permit derived types for
the 'to' and 'from' clauses of 'target update'.
* trans-openmp.cc (gfc_trans_omp_clauses): Fixes for
derived-type changes; fix size for scalars.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/target-11.f90: New test.
* testsuite/libgomp.fortran/target-13.f90: New test.
Please note that(insn 1110) uses register BX, but its
initialization was eliminated.
Avoid conversion if eliminated move intialized a register, used
in the moved instruction.
2022-11-03 Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog:
PR target/107404
* config/i386/i386.md (eliminate reg-reg move by inverting the
condition of a cmove #2 peephole2): Check if eliminated move
initialized a register, used in the moved instruction.
gcc/testsuite/ChangeLog:
PR target/107404
* g++.target/i386/pr107404.C: New test.
Kewen Lin [Thu, 3 Nov 2022 06:22:45 +0000 (01:22 -0500)]
testsuite: Fix gen-vect-34.c with vect_masked_load [PR106806]
This is to fix the failure on powerpc as reported in PR106806,
the test case requires tree ifcvt pass to perform on that loop,
and it relies on masked_load support. The fix is to guard the
expected scan with vect_masked_load effective target.
As tested on powerpc64{,le}-linux-gnu and aarch64-linux-gnu
(cfarm machine), the failures were gone. But on
x86_64-redhat-linux (cfarm machine) the result becomes from
PASS to N/A. I think it's expected since that machine doesn't
support AVX by default so both check_avx_available and
vect_masked_load fail, it should work fine on machines with
default AVX support, or if we adjust the current
check_avx_available with current_compiler_flags.
PR testsuite/106806
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/gen-vect-34.c: Adjust with vect_masked_load
effective target.
Joseph Myers [Thu, 3 Nov 2022 02:53:41 +0000 (02:53 +0000)]
c: C2x auto
Implement C2x auto, a more restricted version of the C++ feature
(closer to GNU C __auto_type in terms of what's supported).
Since the feature is very close to GNU C __auto_type, much of the
implementation can be shared. The main differences are:
* Any prior declaration of the identifier in an outer scope is
shadowed during the initializer (whereas __auto_type leaves any such
declaration visible until the initializer ends and the scope of the
__auto_type declaration itself starts). (A prior declaration in the
same scope is undefined behavior.)
* The standard feature supports braced initializers (containing a
single expression, optionally followed by a comma).
* The standard feature disallows the declaration from declaring
anything that's not an ordinary identifier (thus, the initializer
cannot declare a tag or the members of a structure or union), while
making it undefined behavior for it to declare more than one
ordinary identifier. (For the latter, while I keep the existing
error from __auto_type in the case of more than one declarator, I
don't restrict other ordinary identifiers from being declared in
inner scopes such as GNU statement expressions. I do however
disallow defining the members of an enumeration inside the
initializer (if the enum definition has no tag, that doesn't
actually violate a constraint), to avoid an enum type becoming
accessible beyond where it would have been without auto.
(Preventing new types from escaping the initializer - thus, ensuring
that anything written with auto corresponds to something that could
have been written without auto, modulo multiple evaluation of VLA
size expressions when not using auto - is a key motivation for some
restrictions on what can be declared in the initializer.)
The rule on shadowing and restrictions on other declarations in the
initializer are actually general rules for what C2x calls
underspecified declarations, a description that covers constexpr as
well as auto (in particular, this disallows a constexpr initializer
from referencing the variable being initialized). Thus, some of the
code added for those restrictions will also be of use in implementing
C2x constexpr.
auto with a type specifier remains a storage class specifier with the
same meaning as before (i.e. a redundant storage class specifier for
use at block scope).
Note that the feature is only enabled in C2x mode (-std=c2x or
-std=gnu2x); in older modes, a declaration with auto and no type is
treated as a case of implicit int (only accepted at block scope).
Since many of the restrictions on C2x auto are specified as undefined
behavior rather than constraint violations, it would be possible to
support more features from C++ auto without requiring diagnostics (but
maybe not a good idea, if it isn't clear exactly what semantics might
be given to such a feature in a future revision of C; and
-Wc23-c2y-compat should arguably warn for any such future feature
anyway). For now the features are limited to something close to
what's supported with __auto_type, with the differences as discussed
above between the two features.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/c/
* c-decl.cc (in_underspecified_init, start_underspecified_init)
(finish_underspecified_init): New.
(shadow_tag_warned, parser_xref_tag, start_struct, start_enum):
Give errors inside initializers of underspecified declarations.
(grokdeclarator): Handle (erroneous) case of C2X auto on a
parameter.
(declspecs_add_type): Handle c2x_auto_p case.
(declspecs_add_scspec): Handle auto possibly setting c2x_auto_p in
C2X mode.
(finish_declspecs): Handle c2x_auto_p.
* c-parser.cc (c_parser_declaration_or_fndef): Handle C2X auto.
* c-tree.h (C_DECL_UNDERSPECIFIED): New macro.
(struct c_declspecs): Add c2x_auto_p.
(start_underspecified_init, finish_underspecified_init): New
prototypes.
* c-typeck.cc (build_external_ref): Give error for underspecified
declaration referenced in its initializer.
gcc/testsuite/
* gcc.dg/c2x-auto-1.c, gcc.dg/c2x-auto-2.c, gcc.dg/c2x-auto-3.c,
gcc.dg/c2x-auto-4.c, gcc.dg/gnu2x-auto-1.c: New tests.
... which is 'libgomp.oacc-fortran/declare-allocatable-1.f90' adjusted
for missing support for OpenACC "Changes from Version 2.0 to 2.5":
"The 'declare create' directive with a Fortran 'allocatable' has new behavior".
Thus, after 'allocate'/before 'deallocate', call 'acc_create'/'acc_delete'
manually.
gcc: honour -ffile-prefix-map in ASM_MAP [PR93371]
-ffile-prefix-map is supposed to be a superset of -fmacro-prefix-map
and -fdebug-prefix-map. However, when building .S or .s files, gas is
not called with the appropriate --debug-prefix-map option when
-ffile-prefix-map is used.
While the user can specify -fdebug-prefix-map when building assembly
files via gcc, it's more ergonomic to also support -ffile-prefix-map;
especially since for .S files that could contain the __FILE__ macro,
one would then also have to specify -fmacro-prefix-map.
Patrick Palka [Wed, 2 Nov 2022 12:56:59 +0000 (08:56 -0400)]
libstdc++: Improve ERANGE behavior for fallback FP std::from_chars
The fallback implementation of floating-point std::from_chars (used for
formats other than binary32/64) just calls the C library's strtod family
of functions. In case of overflow, the behavior of these functions is
rigidly specified:
If the correct value overflows and default rounding is in effect, plus
or minus HUGE_VAL, HUGE_VALF, or HUGE_VALL is returned (according to
the return type and sign of the value), and the value of the macro
ERANGE is stored in errno.
But in case of underflow, implementations are given more leeway:
If the result underflows the functions return a value whose magnitude
is no greater than the smallest normalized positive number in the
return type; whether errno acquires the value ERANGE is
implementation-defined.
Thus the fallback implementation can (and does) portably detect overflow,
but it can't portably detect underflow. However, glibc (and presumably
other high-quality C library implementations) will reliably set errno to
ERANGE in case of underflow as well, and it'll also return the nearest
denormal number to the correct value (zero in case of true underflow),
which allows callers to succesfully parse denormal numbers.
So since we can't be perfect here, this patch takes the best effort
approach of assuming a high quality C library implementation with
respect to this underflow behavior, and refines our implementation
to try to distiguish between a denormal result and true underflow
by inspecting strtod's return value.
libstdc++-v3/ChangeLog:
* src/c++17/floating_from_chars.cc (from_chars_impl): In the
ERANGE case, distinguish between a denormal result and true
underflow by checking if the return value is 0.
Jonathan Wakely [Tue, 1 Nov 2022 13:47:24 +0000 (13:47 +0000)]
libstdc++: Remove unnecessary variant member in std::expected
Hui Xie pointed out that we don't need a dummy member in the union,
because all constructors always initialize either _M_val or _M_unex.
We still need the _M_void member of the expected<void, E>
specialization, because the constructor has to initialize something when
not using the _M_unex member.
Jakub Jelinek [Wed, 2 Nov 2022 12:35:53 +0000 (13:35 +0100)]
libstdc++: _Bfloat16 for <compare>
Jon pointed out that we have TODO: _Bfloat16 in <compare>.
Right now _S_fp_fmt() returns _Binary16 for _Float16, __fp16 as well
as __bf16 and it actually works because we don't have a special handling
of _Binary16. So, either we could just document that, but I'm a little bit
afraid if HPPA or MIPS don't start supporting _Float16 and/or __bf16.
If they do, we have the
#if defined __hppa__ || (defined __mips__ && !defined __mips_nan2008)
// IEEE 754-1985 allowed the meaning of the quiet/signaling
// bit to be reversed. Flip that to give desired ordering.
if (__builtin_isnan(__x) && __builtin_isnan(__y))
{
using _Int = decltype(__ix);
constexpr int __nantype = __fmt == _Binary32 ? 22
: __fmt == _Binary64 ? 51
: __fmt == _Binary128 ? 111
: -1;
constexpr _Int __bit = _Int(1) << __nantype;
__ix ^= __bit;
__iy ^= __bit;
}
#endif
code, the only one where we actually care whether something is
_Binary{32,64,128} (elsewhere we just care about the x86 and m68k 80bits
or double double or just floating point type's sizeof) and we'd need
to handle there _Binary16 and/or _Bfloat16.
So this patch uses different enum for it even when it isn't needed right
now, after all _Binary16 isn't needed either and we could just use
_Binary32...
2022-11-02 Jakub Jelinek <jakub@redhat.com>
* libsupc++/compare (_Strong_order::_Fp_fmt): Add _Bfloat16.
(_Strong_order::_Bfloat16): New static data member.
(_Strong_order::_S_fp_fmt): Return _Bfloat16 for std::bfloat16_t.
Rainer Orth [Wed, 2 Nov 2022 09:52:59 +0000 (10:52 +0100)]
builtins: Guard builtins.cc against HUGE_VAL and NAN definitions
trunk bootstrap recently broke on Solaris like this:
/vol/gcc/src/hg/master/local/gcc/builtins.cc:2104:8: error: pasting
"CFN_BUILT_IN_" and "(" does not give a valid preprocessing token
2104 | case CFN_BUILT_IN_##MATHFN: \
| ^~~~~~~~~~~~~
/vol/gcc/src/hg/master/local/gcc/builtins.cc:2112:3: note: in expansion of
macro 'CASE_MATHFN'
2112 | CASE_MATHFN(MATHFN) \
| ^~~~~~~~~~~
/vol/gcc/src/hg/master/local/gcc/builtins.cc:1967:5: note: in expansion of macro 'CASE_MATHFN_FLOATN'
1967 | CASE_MATHFN_FLOATN (HUGE_VAL) \
and similarly for NAN.
It turns out this happens because <math.h> is included at some point,
which (in <iso/math_c99.h>) defines
While this only happpens on Solaris right now, the same issue would be
present on other targets when <math.h> gets included somehow.
To avoid this, this patch #undef's both macros.
Bootstrapped without regressions on i386-pc-solaris2.11 and
sparc-sun-solaris2.11.
Jakub Jelinek [Wed, 2 Nov 2022 09:06:24 +0000 (10:06 +0100)]
libstdc++: Shortest denormal hex std::to_chars
On Fri, Oct 28, 2022 at 12:52:44PM -0400, Patrick Palka wrote:
> > The following patch on top of
> > https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
> > adds std::{,b}float16_t support for std::to_chars.
> > When precision is specified (or for std::bfloat16_t for hex mode even if not),
> > I believe we can just use the std::to_chars float (when float is mode
> > compatible with std::float32_t) overloads, both formats are proper subsets
> > of std::float32_t.
> > Unfortunately when precision is not specified and we are supposed to emit
> > shortest string, the std::{,b}float16_t strings are usually much shorter.
> > E.g. 1.e7p-14f16 shortest fixed representation is
> > 0.0001161 and shortest scientific representation is
> > 1.161e-04 while 1.e7p-14f32 (same number promoted to std::float32_t)
> > 0.00011610985 and
> > 1.1610985e-04.
> > Similarly for 1.38p-112bf16,
> > 0.000000000000000000000000000000000235
> > 2.35e-34 vs. 1.38p-112f32
> > 0.00000000000000000000000000000000023472271
> > 2.3472271e-34
> > For std::float16_t there are differences even in the shortest hex, say:
> > 0.01p-14 vs. 1p-22
> > but only for denormal std::float16_t values (where all std::float16_t
> > denormals converted to std::float32_t are normal), __FLT16_MIN__ and
> > everything larger in absolute value than that is the same. Unless
> > that is a bug and we should try to discover shorter representations
> > even for denormals...
>
> IIRC for hex formatting of denormals I opted to be consistent with how
> glibc printf formats them, instead of outputting the truly shortest
> form.
>
> I wouldn't be against using the float32 overloads even for shortest hex
> formatting of float16. The output is shorter but equivalent so it
> shouldn't cause any problems.
The following patch changes the behavior of the shortest hex denormals,
such that they are printed like normals (so for has_implicit_leading_bit
with 1p-149 instead of 0.000002p-126 etc., otherwise (Intel extended)
with the leading digit before dot being [89abcdef]). I think for all the
supported format it is never longer, it can be equal length e.g. for
0.fffffep-126 vs. 1.fffffcp-127 but fortunately no largest subnormal
in any format has the unbiased exponent like -9, -99, -999, -9999 because
then it would be longer and often it is shorter, sometimes much shorter.
For the cases with precision it keeps the handling as is.
While for !has_implicit_leading_bit we for normals or with this patch
even denormals have really shortest representation, for other formats
we sometimes do not, but this patch doesn't deal with that (we
always use 1.NNN while we could use 1.NNN up to f.NNN and by that shortening
by the last hexit if the last hexit doesn't have least significant bit set
and unbiased exponent is not -9, -99, -999 or -9999.
2022-11-02 Jakub Jelinek <jakub@redhat.com>
* src/c++17/floating_to_chars.cc (__floating_to_chars_hex): Drop const
from unbiased_exponent. Canonicalize denormals such that they have
the leading bit set by shifting effective mantissa up and decreasing
unbiased_exponent.
(__floating_to_chars_shortest): Don't instantiate
__floating_to_chars_hex for float16_t either and use float instead.
* testsuite/20_util/to_chars/float.cc (float_to_chars_test_cases):
Adjust testcases for shortest hex denormals.
* testsuite/20_util/to_chars/double.cc (double_to_chars_test_cases):
Likewise.
Xionghu Luo [Wed, 12 Oct 2022 02:43:38 +0000 (10:43 +0800)]
rs6000: Byte reverse V8HI on Power8 by vector rotation.
gcc/
PR target/100866
* config/rs6000/altivec.md: (*altivec_vrl<VI_char>): Named to...
(altivec_vrl<VI_char>): ...this.
* config/rs6000/vsx.md (revb_<mode>): Call vspltish and vrlh when
target is Power8 and mode is V8HI.
This implements ABI-compliant lambda discriminators. Not only do we
have per-scope counters, but we also distinguish by lambda signature.
Only lambdas with the same signature will need non-zero
discriminators. As the discriminator is signature-dependent, we have
to process the lambda function's declaration before we can determine
it. For templated and generic lambdas the signature is that of the
uninstantiated lambda -- not separate for each instantiation.
With this change, gcc and clang now produce the same lambda manglings
for all these testcases.
gcc/cp/
* cp-tree.h (LAMBDA_EXPR_SCOPE_SIG_DISCRIMINATOR): New.
(struct tree_lambda_expr): Add discriminator_sig bitfield.
(recrd_lambda_scope_sig_discriminator): Declare.
* lambda.cc (struct lambda_sig_count): New.
(lambda_discriminator): Add signature vector.
(start_lambda_scope): Adjust.
(compare_lambda_template_head, compare_lambda_sig): New.
(record_lambda_scope_sig_discriminator): New.
* mangle.cc (write_closure_type): Use the scope-sig discriminator for
ABI >= 18. Emit abi mangling warning if needed.
* module.cc (trees_out::core_vals): Stream the new discriminator.
(trees_in::core_vals): Likewise.
* parser.cc (cp_parser_lambda_declarator_opt): Call
record_lambda_scope_sig_discriminator.
* pt.cc (tsubst_lambda_expr): Likewise.
libcc1/
* libcp1plugin.cc (plugin_start_lambda_closure_class_type):
Initialize the per-scope, per-signature discriminator.
gcc/testsuite/
* g++.dg/abi/lambda-sig1-18.C: New.
* g++.dg/abi/lambda-sig1-18vs17.C: New.
* g++.dg/cpp1y/lambda-mangle-1-18.C: New.
David Seifert [Tue, 1 Nov 2022 20:27:53 +0000 (14:27 -0600)]
configure: cache result of "sys/sdt.h" header check
Use AC_CACHE_CHECK to store the result of the header check for
systemtap's "sys/sdt.h", which is similar in spirit to libstdc++'s
AC_CACHE_CHECK(..., glibcxx_cv_sys_sdt_h).
Richard Purdie [Tue, 1 Nov 2022 19:45:08 +0000 (13:45 -0600)]
gcc/file-prefix-map: Allow remapping of relative paths
Relative paths currently aren't remapped by -ffile-prefix-map and friends.
When cross compiling with separate 'source' and 'build' directories, the same
relative paths between directories may not be available on target as compared
to build time.
In order to be able to remap these relative build paths to paths that would
work on target, resolve paths within the file-prefix-map function using
realpath().
This does cause a change of behaviour if users were previously relying upon
symlinks or absolute paths not being resolved.
Use basename to ensure plain filenames don't have paths added.
gcc/ChangeLog:
* file-prefix-map.cc (remap_filename): Allow remapping of relative paths.
Aldy Hernandez [Tue, 1 Nov 2022 16:27:39 +0000 (17:27 +0100)]
[PR tree-optimization/107490] Handle NANs in op[12]_range.
None of the build_<OP> functions in range-op handle NANs. This is by
design in order to force us to handle NANs specially, because
"x relop NAN" makes no sense. This patch fixes a handful of
op[12]_range entries that weren't handling NANs.
Andrew MacLeod [Mon, 31 Oct 2022 19:18:00 +0000 (15:18 -0400)]
Remove builtin_unreachable in VRP
Removal of __builtin_unreachable calls were handled in an inconsistent
way. This removes then in the VRP pass, and sets the global range
appropriately.
Andrew MacLeod [Mon, 31 Oct 2022 14:56:25 +0000 (10:56 -0400)]
Allow queries on exit block.
Ranger was not allowing the exit block to be queried for range_on_entry
or exit. This removes that restriction.
* gimple-range-cache.cc (ranger_cache::fill_block_cache): Allow
exit block to be specified.
(ranger_cache::range_from_dom): If exit block is specified, use
the immediate predecessor instead of the dominator to start.
* gimple-range.cc (gimple_ranger::range_on_exit): Allow query
for exit block.
Jakub Jelinek [Tue, 1 Nov 2022 12:41:57 +0000 (13:41 +0100)]
libstdc++: std::from_chars std::{,b}float16_t support
The following patch adds std::from_chars support, similarly to the
previous std::to_chars patch through APIs that use float instead of
the 16-bit floating point formats as container.
The patch uses the fast_float library and doesn't need any changes
to it, like the previous patch it introduces wrapper classes around
float that represent the float holding float16_t or bfloat16_t value,
and specializes binary_format etc. from fast_float for these classes.
The new test verifies exhaustively to_chars and from_chars afterward
results in the original value (except for nans) in all the fmt cases.
2022-11-01 Jakub Jelinek <jakub@redhat.com>
* include/std/charconv (__from_chars_float16_t,
__from_chars_bfloat16_t): Declare.
(from_chars): Add _Float16 and __gnu_cxx::__bfloat16_t overloads.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.31): Export
_ZSt22__from_chars_float16_tPKcS0_RfSt12chars_format and
_ZSt23__from_chars_bfloat16_tPKcS0_RfSt12chars_format.
* src/c++17/floating_from_chars.cc
(fast_float::floating_type_float16_t,
fast_float::floating_type_bfloat16_t): New classes.
(fast_float::binary_format<floating_type_float16_t>,
fast_float::binary_format<floating_type_bfloat16_t>): New
specializations.
(fast_float::to_float<floating_type_float16_t>,
fast_float::to_float<floating_type_bfloat16_t>,
fast_float::to_extended<floating_type_float16_t>,
fast_float::to_extended<floating_type_bfloat16_t>): Likewise.
(fast_float::from_chars_16): New template function.
(__floating_from_chars_hex): Allow instantiation with
fast_float::floating_type_{,b}float16_t.
(from_chars): Formatting fixes for float/double/long double overloads.
(__from_chars_float16_t, __from_chars_bfloat16_t): New functions.
* testsuite/20_util/to_chars/float16_c++23.cc: New test.
Jakub Jelinek [Tue, 1 Nov 2022 12:40:05 +0000 (13:40 +0100)]
libstdc++: std::to_chars std::{,b}float16_t support
The following patch on top of
https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
adds std::{,b}float16_t support for std::to_chars.
When precision is specified (or for std::bfloat16_t for hex mode even if not),
I believe we can just use the std::to_chars float (when float is mode
compatible with std::float32_t) overloads, both formats are proper subsets
of std::float32_t.
Unfortunately when precision is not specified and we are supposed to emit
shortest string, the std::{,b}float16_t strings are usually much shorter.
E.g. 1.e7p-14f16 shortest fixed representation is
0.0001161 and shortest scientific representation is
1.161e-04 while 1.e7p-14f32 (same number promoted to std::float32_t)
0.00011610985 and
1.1610985e-04.
Similarly for 1.38p-112bf16,
0.000000000000000000000000000000000235
2.35e-34 vs. 1.38p-112f32
0.00000000000000000000000000000000023472271
2.3472271e-34
For std::float16_t there are differences even in the shortest hex, say:
0.01p-14 vs. 1p-22
but only for denormal std::float16_t values (where all std::float16_t
denormals converted to std::float32_t are normal), __FLT16_MIN__ and
everything larger in absolute value than that is the same. Unless
that is a bug and we should try to discover shorter representations
even for denormals...
std::bfloat16_t has the same exponent range as std::float32_t, so all
std::bfloat16_t denormals are also std::float32_t denormals and thus
the shortest hex representations are the same.
As documented, ryu can handle arbitrary IEEE like floating point formats
(probably not wider than IEEE quad) using the generic_128 handling, but
ryu is hidden in libstdc++.so. As only few architectures support
std::float16_t right now and some of them have special ISA requirements
for those (e.g. on i?86 one needs -msse2) and std::bfloat16_t is right
now supported only on x86 (again with -msse2), perhaps with aarch64/arm
coming next if ARM is interested, but I think it is possible that more
will be added later, instead of exporting APIs from the library to handle
directly the std::{,b}float16_t overloads this patch instead exports
functions which take a float which is a superset of those and expects
the inline overloads to promote the 16-bit formats to 32-bit, then inside
of the library it ensures they are printed right.
With the added [[gnu::cold]] attribute because I think most users
will primarily use these formats as storage formats and perform arithmetics
in the excess precision for them and print also as std::float32_t the
added support doesn't seem to be too large, on x86_64:
readelf -Ws libstdc++.so.6.0.31 | grep float16_t
912: 00000000000ae824 950 FUNC GLOBAL DEFAULT 13 _ZSt21__to_chars_bfloat16_tPcS_fSt12chars_format@@GLIBCXX_3.4.31
5767: 00000000000ae4a1 899 FUNC GLOBAL DEFAULT 13 _ZSt20__to_chars_float16_tPcS_fSt12chars_format@@GLIBCXX_3.4.31
842: 000000000016d430 106 FUNC LOCAL DEFAULT 13 _ZN12_GLOBAL__N_113get_ieee_reprINS_23floating_type_float16_tEEENS_6ieee_tIT_EES3_
865: 0000000000170980 1613 FUNC LOCAL DEFAULT 13
+_ZSt23__floating_to_chars_hexIN12_GLOBAL__N_123floating_type_float16_tEESt15to_chars_resultPcS3_T_St8optionalIiE.constprop.0.isra.0
7205: 00000000000ae824 950 FUNC GLOBAL DEFAULT 13 _ZSt21__to_chars_bfloat16_tPcS_fSt12chars_format
7985: 00000000000ae4a1 899 FUNC GLOBAL DEFAULT 13 _ZSt20__to_chars_float16_tPcS_fSt12chars_format
so 3568 code bytes together or so.
Tested with the attached test (which doesn't prove the shortest
representation, just prints std::{,b}float16_t and std::float32_t
shortest strings side by side, then tries to verify it can be
emitted even into the exact sized range and can't be into range
one smaller than that and tries to read what is printed
back using from_chars float32_t overload (so there could be
double rounding, but apparently there is none for the shortest strings).
The only differences printed are for NaNs, where sNaNs are canonicalized
to canonical qNaNs and as to_chars doesn't print NaN mantissa, even qNaNs
other than the canonical one are read back just as the canonical NaN.
Also attaching what Patrick wrote to generate the pow10_adjustment_tab,
for std::float16_t only 1.0, 10.0, 100.0, 1000.0 and 10000.0 are powers
of 10 in the range because __FLT16_MAX__ is 65504.0, and all of the above
are exactly representable in std::float16_t, so we want to use 0 in
pow10_adjustment_tab.
2022-11-01 Jakub Jelinek <jakub@redhat.com>
* include/std/charconv (__to_chars_float16_t, __to_chars_bfloat16_t):
Declare.
(to_chars): Add _Float16 and __gnu_cxx::__bfloat16_t overloads.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.31): Export
_ZSt20__to_chars_float16_tPcS_fSt12chars_format and
_ZSt21__to_chars_bfloat16_tPcS_fSt12chars_format.
* src/c++17/floating_to_chars.cc (floating_type_float16_t,
floating_type_bfloat16_t): New types.
(floating_type_traits<floating_type_float16_t>,
floating_type_traits<floating_type_bfloat16_t>,
get_ieee_repr<floating_type_float16_t>,
get_ieee_repr<floating_type_bfloat16_t>,
__handle_special_value<floating_type_float16_t>,
__handle_special_value<floating_type_bfloat16_t>): New specializations.
(floating_to_shortest_scientific): Handle floating_type_float16_t
and floating_type_bfloat16_t like IEEE quad.
(__floating_to_chars_shortest): For floating_type_bfloat16_t call
__floating_to_chars_hex<float> rather than
__floating_to_chars_hex<floating_type_bfloat16_t> to avoid
instantiating the latter.
(__to_chars_float16_t, __to_chars_bfloat16_t): New functions.
Jakub Jelinek [Tue, 1 Nov 2022 12:34:51 +0000 (13:34 +0100)]
libstdc++-v3: Some std::*float*_t charconv and i/ostream overloads
The following patch adds the easy part of <charconv>, <istream> and
<ostream> changes for extended floats.
In particular, for the first one only overloads where the _Float* has
the same format as float/double/long double and for the latter two
everything but the _GLIBCXX_HAVE_FLOAT128_MATH case.
For charconv, I'm not really familiar with it, I'm pretty sure
we need new libstdc++.so.6 side implementation of from_chars for
{,b}float16_t and for to_chars not really sure but for unspecified precision
if it should emit minimum characters that to_chars then can unambiguously
parse, I think it is less than in the float case. For float128_t
{to,from}_chars I think we even have it on the library side already, just
ifdefed for powerpc64le only.
For i/o stream operator<</>>, not sure what is better, if not providing
anything at all, or doing what we in the end do if user doesn't override
the virtual functions, or use {to,from}_chars under the hood, something
else?
Besides this, the patch adds some further missed
// { dg-options "-std=gnu++2b" }
spots, I've also noticed I got the formatting wrong in some testcases
by not using spaces around VERIFY conditions and elsewhere by having
space before ( for calls.
The testsuite coverage is limited, I've added test for from_chars because
it was easy to port, but not really sure what to do about to_chars, it has
for float/double huge testcases which would be excessive to repeat.
And for i/ostream not really sure what exactly is worth testing.
2022-11-01 Jakub Jelinek <jakub@redhat.com>
* include/std/charconv (from_chars, to_chars): Add _Float{32,64,128}
overloads for cases where those types match {float,double,long double}.
* include/std/istream (basic_istream::operator>>): Add
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t overloads.
* include/std/ostream (basic_ostream::operator<<): Add
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t overloads.
* testsuite/20_util/from_chars/8.cc: New test.
* testsuite/26_numerics/headers/cmath/nextafter_c++23.cc (test):
Formatting fixes.
* testsuite/26_numerics/headers/cmath/functions_std_c++23.cc: Add
dg-options "-std=gnu++2b".
(test_functions, main): Formatting fixes.
* testsuite/26_numerics/headers/cmath/c99_classification_macros_c++23.cc:
Add dg-options "-std=gnu++2b".
which says that DImode idiv has latency 41 (which is correct) and that
it occupies 2nd integer execution unit for 41 consecutive cycles, but
that is not correct:
1) the division instruction is partially pipelined, and has throughput
1/14, not 1/41;
2) for the most part it occupies a separate division unit, not the
general arithmetic unit.
Evidently, interaction of such 41-cycle paths with the rest of
reservations causes a combinatorial explosion in the automaton.
Fix this by modeling the integer division unit properly, and correcting
reservations to use the measured reciprocal throughput of those
instructions (available from uops.info). A similar correction for
floating-point divisions is left for a followup patch.
Top 5 znver table sizes, before:
68692 r znver1_ieu_check
68692 r znver1_ieu_transitions
99792 r znver1_ieu_min_issue_delay
428108 r znver1_fp_min_issue_delay
856216 r znver1_fp_transitions
After:
1454 r znver1_ieu_translate
1454 r znver1_translate
2304 r znver1_ieu_transitions
428108 r znver1_fp_min_issue_delay
856216 r znver1_fp_transitions
gcc/ChangeLog:
PR target/87832
* config/i386/znver.md (znver1_idiv): New automaton.
(znver1-idiv): New unit.
(znver1_idiv_DI): Correct unit and cycles in the reservation.
(znver1_idiv_SI): Ditto.
(znver1_idiv_HI): Ditto.
(znver1_idiv_QI): Ditto.
(znver1_idiv_mem_DI): Ditto.
(znver1_idiv_mem_SI): Ditto.
(znver1_idiv_mem_HI): Ditto.
(znver1_idiv_mem_QI): Ditto.
(znver3_idiv_DI): Ditto.
(znver3_idiv_SI): Ditto.
(znver3_idiv_HI): Ditto.
(znver3_idiv_QI): Ditto.
(znver3_idiv_mem_DI): Ditto.
(znver3_idiv_mem_SI): Ditto.
(znver3_idiv_mem_HI): Ditto.
(znver3_idiv_mem_QI): Ditto.
Nathan Sidwell [Mon, 31 Oct 2022 10:11:28 +0000 (06:11 -0400)]
c++: Reorganize per-scope lambda discriminators
We currently use a per-extra-scope counter to discriminate multiple
lambdas in a particular such scope. This is not ABI compliant. This
patch merely refactors the existing code to make it easier to drop in
a conformant mangling -- there's no functional change here. I rename
the LAMBDA_EXPR_DISCIMINATOR to LAMBDA_EXPR_SCOPE_ONLY_DISCRIMINATOR,
foreshadowing that there'll be a new discriminator. To provide ABI
warnings we'll need to calculate both, and that requires some
repacking of the lambda_expr's fields. Finally, although we end up
calling the discriminator setter and the scope recorder (nearly)
always consecutively, it's clearer to handle it as two separate
operations. That also allows us to remove the instantiation
special-case for a null extra-scope.
gcc/cp/
* cp-tree.h (LAMBDA_EXPR_DISCRIMINATOR): Rename to ...
(LAMBDA_EXPR_SCOPE_ONLY_DISCRIMINATOR): ... here.
(struct tree_lambda_expr): Make default_capture_mode &
discriminator_scope bitfields.
(record_null_lambda_scope) Delete.
(record_lambda_scope_discriminator): Declare.
* lambda.cc (struct lambda_discriminator): New struct.
(lambda_scope, lambda_scope_stack): Adjust types.
(lambda_count): Delete.
(struct tree_int): Delete.
(start_lambda_scope, finish_lambda_scope): Adjust.
(record_lambda_scope): Only record the scope.
(record_lambda_scope_discriminator): New.
* mangle.cc (write_closure_type_name): Adjust.
* module.cc (trees_out::core_vals): Likewise,
(trees_in::core_vals): Likewise.
* parser.cc (cp_parser_lambda_expression): Call
record_lambda_scope_discriminator.
* pt.cc (tsubst_lambda_expr): Adjust record_lambda_scope caling. Call
record_lambda_scope_discriminator. Commonize control flow on tsubsting
the operator function.
libcc1/
* libcp1plugin.cc (plugin_start_closure): Adjust.
gcc/testsuite/
* g++.dg/abi/lambda-sig1-17.C: New.
* g++.dg/abi/lambda-sig1.h: New.
* g++.dg/cpp1y/lambda-mangle-1.C: Extracted to ...
* g++.dg/cpp1y/lambda-mangle-1.h: ... here.
* g++.dg/cpp1y/lambda-mangle-1-11.C: New
* g++.dg/cpp1y/lambda-mangle-1-17.C
liuhongt [Tue, 25 Oct 2022 09:10:23 +0000 (17:10 +0800)]
Fix incorrect digit constraint
Matching constraints are used in these circumstances. More precisely,
the two operands that match must include one input-only operand and
one output-only operand. Moreover, the digit must be a smaller number
than the number of the operand that uses it in the constraint.
In pr107057, the 2 operands in the pattern are both input operands.
gcc/ChangeLog:
PR target/107057
* config/i386/sse.md (*vec_interleave_highv2df): Remove
constraint 1.
(*vec_interleave_lowv2df): Ditto.
(vec_concatv2df): Ditto.
(*avx512f_unpcklpd512<mask_name>): Ditto and renamed to ..
(avx512f_unpcklpd512<mask_name>): .. this.
(avx512f_movddup512<mask_name>): Change to define_insn.
(avx_movddup256<mask_name>): Ditto.
(*avx_unpcklpd256<mask_name>): Remove constraint 1 and renamed
to ..
(avx_unpcklpd256<mask_name>): .. this.
* config/i386/i386.cc (ix86_vec_interleave_v2df_operator_ok):
Disallow MEM_P (op1) && MEM_P (op2).
liuhongt [Thu, 27 Oct 2022 10:48:41 +0000 (18:48 +0800)]
Enable more optimization for 32-bit/64-bit shrd/shld with imm shift count.
This patch doens't handle variable count since it require 5 insns to
be combined to get wanted pattern, but current pass_combine only
supports at most 4.
This patch doesn't handle 16-bit shrd/shld either.
gcc/ChangeLog:
PR target/55583
* config/i386/i386.md (*x86_64_shld_1): Rename to ..
(x86_64_shld_1): .. this.
(*x86_shld_1): Rename to ..
(x86_shld_1): .. this.
(*x86_64_shrd_1): Rename to ..
(x86_64_shrd_1): .. this.
(*x86_shrd_1): Rename to ..
(x86_shrd_1): .. this.
(*x86_64_shld_shrd_1_nozext): New pre_reload splitter.
(*x86_shld_shrd_1_nozext): Ditto.
(*x86_64_shrd_shld_1_nozext): Ditto.
(*x86_shrd_shld_1_nozext): Ditto.
Cui,Lili [Tue, 1 Nov 2022 01:16:49 +0000 (09:16 +0800)]
Add attribute hot judgement for INLINE_HINT_known_hot hint.
We set up INLINE_HINT_known_hot hint only when we have profile feedback,
now add function attribute judgement for it, when both caller and callee
have __attribute__((hot)), we will also set up INLINE_HINT_known_hot hint
for it.
With this patch applied,
ADL Multi-copy: 538.imagic_r 16.7%
ICX Multi-copy: 538.imagic_r 15.2%
CLX Multi-copy: 538.imagic_r 12.7%
Znver3 Multi-copy: 538.imagic_r 10.6%
Arm Multi-copy: 538.imagic_r 13.4%
gcc/ChangeLog
* ipa-inline-analysis.cc (do_estimate_edge_time): Add function attribute
judgement for INLINE_HINT_known_hot hint.
Jakub Jelinek [Mon, 31 Oct 2022 19:13:02 +0000 (20:13 +0100)]
libstdc++-v3: <complex> support for extended floating point types
The following patch adds <complex> support for extended floating point
types.
C++23 removes the float/double/long double specializations from the spec
and instead adds explicit(bool) specifier on the converting constructor.
The patch uses that for converting constructor of the base template as well
as the float/double/long double specializations's converting constructors
(e.g. so that it handles convertion construction also from complex of extended
floating point types). Copy ctor was already defaulted as the spec now
requires.
The patch also adds partial specialization for the _Float{16,32,64,128}
and __gnu_cxx::__bfloat16_t types because the base template doesn't use
__complex__ but a pair of floating point values.
The g++.dg/cpp23/ testcase verifies explicit(bool) works correctly.
2022-10-31 Jakub Jelinek <jakub@redhat.com>
gcc/testsuite/
* g++.dg/cpp23/ext-floating12.C: New test.
libstdc++-v3/
* include/std/complex (complex::complex converting ctor): For C++23
use explicit specifier with constant expression. Explicitly cast
both parts to _Tp.
(__complex_abs, __complex_arg, __complex_cos, __complex_cosh,
__complex_exp, __complex_log, __complex_sin, __complex_sinh,
__complex_sqrt, __complex_tan, __complex_tanh, __complex_pow): Add
__complex__ _Float{16,32,64,128} and __complex__ decltype(0.0bf16)
overloads.
(complex<float>::complex converting ctor,
complex<double>::complex converting ctor,
complex<long double>::complex converting ctor): For C++23 implement
as template with explicit specifier with constant expression
and explicit casts.
(__complex_type): New template.
(complex): New partial specialization for types with extended floating
point types.
(__complex_acos, __complex_asin, __complex_atan, __complex_acosh,
__complex_asinh, __complex_atanh): Add __complex__ _Float{16,32,64,128}
and __complex__ decltype(0.0bf16) overloads.
(__complex_proj): Likewise. Add template for complex of extended
floating point types.
* include/bits/cpp_type_traits.h (__is_floating): Specialize for
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t.
* testsuite/26_numerics/complex/ext_c++23.cc: New test.
BTF supports 64-bits enumerators with following encoding:
struct btf_type:
name_off: 0 or offset to a valid C identifier
info.kind_flag: 0 for unsigned, 1 for signed
info.kind: BTF_KIND_ENUM64
info.vlen: number of enum values
size: 1/2/4/8
The btf_type is followed by info.vlen number of:
struct btf_enum64
{
uint32_t name_off; /* Offset in string section of enumerator name. */
uint32_t val_lo32; /* lower 32-bit value for a 64-bit value Enumerator */
uint32_t val_hi32; /* high 32-bit value for a 64-bit value Enumerator */
};
So, a new btf_enum64 structure was added to represent BTF_KIND_ENUM64
and a new field dtd_enum_unsigned in ctf_dtdef structure to distinguish
when CTF enum is a signed or unsigned type, later that information is
used to encode the BTF enum type.
gcc/ChangeLog:
* btfout.cc (btf_calc_num_vbytes): Compute enumeration size depending of
enumerator type btf_enum{,64}.
(btf_asm_type): Update btf_kflag according to enumeration type sign
using dtd_enum_unsigned field for both: BTF_KIND_ENUM{,64}.
(btf_asm_enum_const): New argument to represent the size of
the BTF enum type, writing the enumerator constant value for
32 bits, if it's 64 bits then explicitly writes lower 32-bits
value and higher 32-bits value.
(output_asm_btf_enum_list): Add enumeration size argument.
* ctfc.cc (ctf_add_enum): New argument to represent CTF enum
basic information.
(ctf_add_generic): Use of ei_{name. size, unsigned} to build the
dtd structure containing enumeration information.
(ctf_add_enumerator): Update comment mention support for BTF
enumeration in 64-bits.
* dwarf2ctf.cc (gen_ctf_enumeration_type): Extract signedness
for enumeration type and use it in ctf_add_enum.
* ctfc.h (ctf_dmdef): Update dmd_value to HOST_WIDE_INT to allow
use 32/64 bits enumerators.
information.
(ctf_dtdef): New field to describe enum signedness.
include/
* btf.h (btf_enum64): Add new definition and new symbolic
constant to BTF_KIND_ENUM64 and BTF_KF_ENUM_{UN,}SIGNED.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-enum-1.c: Update testcase, with correct
info.kflags encoding.
* gcc.dg/debug/btf/btf-enum64-1.c: New testcase.
Jakub Jelinek [Mon, 31 Oct 2022 15:47:23 +0000 (16:47 +0100)]
libstdc++: Small extended float support tweaks
The following patch
1) enables the std::float128_t overloads for x86 with glibc 2.26+
2) makes std::nextafter(std::float16_t, std::float16_t) and
std::nextafter(std::bfloat16_t, std::bfloat16_t) constexpr
3) adds (small) testsuite coverage for that
2022-10-21 Jakub Jelinek <jakub@redhat.com>
* config/os/gnu-linux/os_defines.h (_GLIBCXX_HAVE_FLOAT128_MATH):
Uncomment.
* include/c_global/cmath (nextafter(_Float16, _Float16)): Make it constexpr.
If std::__is_constant_evaluated() call __builtin_nextafterf16.
(nextafter(__gnu_cxx::__bfloat16_t, __gnu_cxx::__bfloat16_t)): Similarly
but call __builtin_nextafterf16b.
* testsuite/26_numerics/headers/cmath/nextafter_c++23.cc (test): Add
static assertions to test constexpr nextafter.
Ju-Zhe Zhong [Thu, 27 Oct 2022 14:41:52 +0000 (22:41 +0800)]
RISC-V: Change constexpr back to CONSTEXPR
According to https://github.com/gcc-mirror/gcc/commit/f95d3d5de72a1c43e8d529bad3ef59afc3214705.
Since GCC 4.8.6 doesn't support constexpr, we should change it back to CONSTEXPR.
gcc/ChangeLog:
Andrew Stubbs [Fri, 28 Oct 2022 12:09:20 +0000 (13:09 +0100)]
amdgcn: add fmin/fmax patterns
Add fmin/fmax for scalar, vector, and reductions. The smin/smax patterns are
already using the IEEE compliant hardware instructions anyway, so we can just
expand to use those insns.
gcc/ChangeLog:
* config/gcn/gcn-valu.md (fminmaxop): New iterator.
(<fexpander><mode>3): New define_expand.
(<fexpander><mode>3<exec>): Likewise.
(reduc_<fexpander>_scal_<mode>): Likewise.
* config/gcn/gcn.md (fexpander): New attribute.
Andrew Stubbs [Fri, 28 Oct 2022 11:38:43 +0000 (12:38 +0100)]
amdgcn: multi-size vector reductions
Add support for vector reductions for any vector width by switching iterators
and generalising the code slightly. There's no one-instruction way to move an
item from lane 31 to lane 0 (63, 15, 7, 3, and 1 are all fine though), and
vec_extract is probably fewer cycles anyway, so now we always reduce to an
SGPR.
gcc/ChangeLog:
* config/gcn/gcn-valu.md (V64_SI): Delete iterator.
(V64_DI): Likewise.
(V64_1REG): Likewise.
(V64_INT_1REG): Likewise.
(V64_2REG): Likewise.
(V64_ALL): Likewise.
(V64_FP): Likewise.
(reduc_<reduc_op>_scal_<mode>): Use V_ALL. Use gen_vec_extract.
(fold_left_plus_<mode>): Use V_FP.
(*<reduc_op>_dpp_shr_<mode>): Use V_1REG.
(*<reduc_op>_dpp_shr_<mode>): Use V_DI.
(*plus_carry_dpp_shr_<mode>): Use V_INT_1REG.
(*plus_carry_in_dpp_shr_<mode>): Use V_SI.
(*plus_carry_dpp_shr_<mode>): Use V_DI.
(mov_from_lane63_<mode>): Delete.
(mov_from_lane63_<mode>): Delete.
* config/gcn/gcn.cc (gcn_expand_reduc_scalar): Support partial vectors.
* config/gcn/gcn.md (unspec): Remove UNSPEC_MOV_FROM_LANE63.
* vtv-change-permission.h (defined): Determines whether the macro
__loongarch_lp64 is defined
(VTV_PAGE_SIZE): Set VTV_PAGE_SIZE to 16KiB for loongarch64.
Jakub Jelinek [Mon, 31 Oct 2022 08:09:48 +0000 (09:09 +0100)]
builtins: Add various complex builtins for _Float{16,32,64,128,32x,64x,128x}
The following patch adds some complex builtins which have libm
implementation in glibc 2.26 and later on various arches.
It is needed for libstdc++ _Float128 support when long double is not
IEEE quad.
Jakub Jelinek [Mon, 31 Oct 2022 08:07:04 +0000 (09:07 +0100)]
builtins: Add __builtin_nextafterf16b builtin
The following patch adds another needed builtin.
The earlier patch adds among other things __builtin_nextafterf16
builtin which we need in order to constexpr evaluate
std::nextafter(_Float16) overload (patch for that has been posted already).
While there is inline implementation of the overload, it isn't constant
evaluation friendly, and the builtin doesn't need libm implementation
because it will be used only during constant expression evaluation.
We need the same thing also for std::nextafter(__gnu_cxx::__bfloat16_t)
though and this patch does that.
Jakub Jelinek [Mon, 31 Oct 2022 08:05:02 +0000 (09:05 +0100)]
builtins: Add various __builtin_*f{16,32,64,128,32x,64x,128x} builtins
When working on libstdc++ extended float support in <cmath>, I found that
we need various builtins for the _Float{16,32,64,128,32x,64x,128x} types.
Glibc 2.26 and later provides the underlying libm routines (except for
_Float16 and _Float128x for the time being) and in libstdc++ I think we
need at least the _Float128 builtins on x86_64, i?86, powerpc64le and ia64
(when long double is IEEE quad, we can handle it by using __builtin_*l
instead), because without the builtins the overloads couldn't be constexpr
(say when it would declare the *f128 extern "C" routines itself and call
them).
The testcase covers just types of those builtins and their constant
folding, so doesn't need actual libm support.
2022-10-31 Jakub Jelinek <jakub@redhat.com>
* builtin-types.def (BT_FLOAT16_PTR, BT_FLOAT32_PTR, BT_FLOAT64_PTR,
BT_FLOAT128_PTR, BT_FLOAT32X_PTR, BT_FLOAT64X_PTR, BT_FLOAT128X_PTR):
New DEF_PRIMITIVE_TYPE.
(BT_FN_INT_FLOAT16, BT_FN_INT_FLOAT32, BT_FN_INT_FLOAT64,
BT_FN_INT_FLOAT128, BT_FN_INT_FLOAT32X, BT_FN_INT_FLOAT64X,
BT_FN_INT_FLOAT128X, BT_FN_LONG_FLOAT16, BT_FN_LONG_FLOAT32,
BT_FN_LONG_FLOAT64, BT_FN_LONG_FLOAT128, BT_FN_LONG_FLOAT32X,
BT_FN_LONG_FLOAT64X, BT_FN_LONG_FLOAT128X, BT_FN_LONGLONG_FLOAT16,
BT_FN_LONGLONG_FLOAT32, BT_FN_LONGLONG_FLOAT64,
BT_FN_LONGLONG_FLOAT128, BT_FN_LONGLONG_FLOAT32X,
BT_FN_LONGLONG_FLOAT64X, BT_FN_LONGLONG_FLOAT128X): New
DEF_FUNCTION_TYPE_1.
(BT_FN_FLOAT16_FLOAT16_FLOAT16PTR, BT_FN_FLOAT32_FLOAT32_FLOAT32PTR,
BT_FN_FLOAT64_FLOAT64_FLOAT64PTR, BT_FN_FLOAT128_FLOAT128_FLOAT128PTR,
BT_FN_FLOAT32X_FLOAT32X_FLOAT32XPTR,
BT_FN_FLOAT64X_FLOAT64X_FLOAT64XPTR,
BT_FN_FLOAT128X_FLOAT128X_FLOAT128XPTR, BT_FN_FLOAT16_FLOAT16_INT,
BT_FN_FLOAT32_FLOAT32_INT, BT_FN_FLOAT64_FLOAT64_INT,
BT_FN_FLOAT128_FLOAT128_INT, BT_FN_FLOAT32X_FLOAT32X_INT,
BT_FN_FLOAT64X_FLOAT64X_INT, BT_FN_FLOAT128X_FLOAT128X_INT,
BT_FN_FLOAT16_FLOAT16_INTPTR, BT_FN_FLOAT32_FLOAT32_INTPTR,
BT_FN_FLOAT64_FLOAT64_INTPTR, BT_FN_FLOAT128_FLOAT128_INTPTR,
BT_FN_FLOAT32X_FLOAT32X_INTPTR, BT_FN_FLOAT64X_FLOAT64X_INTPTR,
BT_FN_FLOAT128X_FLOAT128X_INTPTR, BT_FN_FLOAT16_FLOAT16_LONG,
BT_FN_FLOAT32_FLOAT32_LONG, BT_FN_FLOAT64_FLOAT64_LONG,
BT_FN_FLOAT128_FLOAT128_LONG, BT_FN_FLOAT32X_FLOAT32X_LONG,
BT_FN_FLOAT64X_FLOAT64X_LONG, BT_FN_FLOAT128X_FLOAT128X_LONG): New
DEF_FUNCTION_TYPE_2.
(BT_FN_FLOAT16_FLOAT16_FLOAT16_INTPTR,
BT_FN_FLOAT32_FLOAT32_FLOAT32_INTPTR,
BT_FN_FLOAT64_FLOAT64_FLOAT64_INTPTR,
BT_FN_FLOAT128_FLOAT128_FLOAT128_INTPTR,
BT_FN_FLOAT32X_FLOAT32X_FLOAT32X_INTPTR,
BT_FN_FLOAT64X_FLOAT64X_FLOAT64X_INTPTR,
BT_FN_FLOAT128X_FLOAT128X_FLOAT128X_INTPTR): New DEF_FUNCTION_TYPE_3.
* builtins.def (ACOSH_TYPE, ATAN2_TYPE, ATANH_TYPE, COSH_TYPE,
FDIM_TYPE, HUGE_VAL_TYPE, HYPOT_TYPE, ILOGB_TYPE, LDEXP_TYPE,
LGAMMA_TYPE, LLRINT_TYPE, LOG10_TYPE, LRINT_TYPE, MODF_TYPE,
NEXTAFTER_TYPE, REMQUO_TYPE, SCALBLN_TYPE, SCALBN_TYPE, SINH_TYPE):
Define and undefine later.
(FMIN_TYPE, SQRT_TYPE): Undefine at a later line.
(INF_TYPE): Define at a later line.
(BUILT_IN_ACOSH, BUILT_IN_ACOS, BUILT_IN_ASINH, BUILT_IN_ASIN,
BUILT_IN_ATAN2, BUILT_IN_ATANH, BUILT_IN_ATAN, BUILT_IN_CBRT,
BUILT_IN_COSH, BUILT_IN_COS, BUILT_IN_ERFC, BUILT_IN_ERF,
BUILT_IN_EXP2, BUILT_IN_EXP, BUILT_IN_EXPM1, BUILT_IN_FDIM,
BUILT_IN_FMOD, BUILT_IN_FREXP, BUILT_IN_HYPOT, BUILT_IN_ILOGB,
BUILT_IN_LDEXP, BUILT_IN_LGAMMA, BUILT_IN_LLRINT, BUILT_IN_LLROUND,
BUILT_IN_LOG10, BUILT_IN_LOG1P, BUILT_IN_LOG2, BUILT_IN_LOGB,
BUILT_IN_LOG, BUILT_IN_LRINT, BUILT_IN_LROUND, BUILT_IN_MODF,
BUILT_IN_NEXTAFTER, BUILT_IN_POW, BUILT_IN_REMAINDER, BUILT_IN_REMQUO,
BUILT_IN_SCALBLN, BUILT_IN_SCALBN, BUILT_IN_SINH, BUILT_IN_SIN,
BUILT_IN_TANH, BUILT_IN_TAN, BUILT_IN_TGAMMA): Add
DEF_EXT_LIB_FLOATN_NX_BUILTINS.
(BUILT_IN_HUGE_VAL): Use HUGE_VAL_TYPE instead of INF_TYPE in
DEF_GCC_FLOATN_NX_BUILTINS.
* fold-const-call.cc (fold_const_call_ss): Add various CASE_CFN_*_FN:
cases when CASE_CFN_* is present.
(fold_const_call_sss): Likewise.
* builtins.cc (mathfn_built_in_2): Use CASE_MATHFN_FLOATN instead of
CASE_MATHFN for various builtins in SEQ_OF_CASE_MATHFN macro.
(builtin_with_linkage_p): Add CASE_FLT_FN_FLOATN_NX for various
builtins next to CASE_FLT_FN.
* fold-const.cc (tree_call_nonnegative_warnv_p): Add CASE_CFN_*_FN:
next to CASE_CFN_*: for various builtins.
* tree-call-cdce.cc (can_test_argument_range): Add
CASE_FLT_FN_FLOATN_NX next to CASE_FLT_FN for various builtins.
(edom_only_function): Likewise.
* gcc.dg/torture/floatn-builtin.h: Add tests for newly added builtins.
liuhongt [Tue, 25 Oct 2022 05:31:54 +0000 (13:31 +0800)]
Enable V4BFmode and V2BFmode.
Enable V4BFmode and V2BFmode with the same ABI as V4HFmode and
V2HFmode. No real operation is supported for them except for movement.
This should solve PR target/107261.
Also I notice there's redundancy in VALID_AVX512FP16_REG_MODE, and
remove V2BFmode remove it.
gcc/ChangeLog:
PR target/107261
* config/i386/i386-modes.def (VECTOR_MODE): Support V2BFmode.
* config/i386/i386.cc (classify_argument): Handle V4BFmode and
V2BFmode.
(ix86_convert_const_vector_to_integer): Ditto.
* config/i386/i386.h (VALID_AVX512FP16_REG_MODE): Remove
V2BFmode.
(VALID_SSE2_REG_MODE): Add V4BFmode and V2BFmode.
(VALID_MMX_REG_MODE): Add V4BFmode.
* config/i386/i386.md (mode): Add V4BF and V2BF.
(MODE_SIZE): Ditto.
* config/i386/mmx.md (MMXMODE) Add V4BF.
(V_32): Add V2BF.
(V_16_32_64): Add V4BF and V2BF.
(mmxinsnmode): Add V4BF and V2BF.
(*mov<mode>_internal): Hanlde V4BFmode and V2BFmode.
broke the alias analysis for the hard frame pointer (when it is used as a
frame pointer, i.e. when the frame pointer is not eliminated) described in
the large comment at the top of the file, because static_reg_base_value is
set for it and, consequently, new_reg_base_value too.
When the instruction saving the stack pointer into the hard frame pointer in
the prologue is processed, it is viewed as a second set of the hard frame
pointer and to a different value by record_set, which then proceeds to reset
new_reg_base_value to 0 and the game is over.
gcc/
* alias.cc (init_alias_analysis): Do not record sets to the hard
frame pointer if the frame pointer has not been eliminated.
- Import dmd v2.101.0-beta.1.
- Add predefined version `D_Optimized' when compiling with `-O'.
- Shortened method syntax (DIP1043) is now enabled by default.
- Array literals assigned to `scope' array variables are now
allocated on the stack.
- Implement `@system' variables (DIP1035), available behind the
preview feature flag `-fpreview=systemvariables'.
D runtime changes:
- Import druntime v2.101.0-beta.1.
Phobos changes:
- Import phobos v2.101.0-beta.1.
- Added `std.typecons.SafeRefCounted', that can be used in `@safe'
code with `-fpreview=dip1000'.
gcc/d/ChangeLog:
* d-attribs.cc (apply_user_attributes): Update for new front-end
interface.
* d-builtins.cc (d_init_versions): Predefine `D_Optimized' with
compiling with optimizations enabled.
* d-lang.cc (d_handle_option): Update for new front-end interface.
Handle new option `-fpreview=systemvariables'.
* dmd/MERGE: Merge upstream dmd e4f8919591.
* dmd/VERSION: Bump version to v2.101.0-beta.1.
* expr.cc (ExprVisitor::visit (AssignExp *)): Treat construction of
static arrays from a call expression as a simple assignment.
(ExprVisitor::visit (ArrayLiteralExp *)): Handle array literals with
`scope' storage.
* gdc.texi: Update documentation of `-fpreview=' options.
* lang.opt (fpreview=shortenedmethods): Remove.
(fpreview=systemvariables): New option.
* gdc.dg/simd19630.d: Move tests with errors to ...
* gdc.dg/simd19630b.d: ... here. New test.
* gdc.dg/simd19630c.d: New test.
* gdc.dg/simd_ctfe.d: Removed.
* gdc.dg/simd18867.d: New test.
* gdc.dg/simd19788.d: New test.
* gdc.dg/simd21469.d: New test.
* gdc.dg/simd21672.d: New test.
* gdc.dg/simd23077.d: New test.
* gdc.dg/simd23084.d: New test.
* gdc.dg/simd23085.d: New test.
* gdc.dg/torture/simd19632.d: New test.
* gdc.dg/torture/simd20041.d: New test.
* gdc.dg/torture/simd21673.d: New test.
* gdc.dg/torture/simd21676.d: New test.
* gdc.dg/torture/simd22438.d: New test.
* gdc.dg/torture/simd23009.d: New test.
* gdc.dg/torture/simd23077.d: New test.
* gdc.dg/torture/simd8.d: New test.
* gdc.dg/torture/simd9.d: New test.
* gdc.dg/torture/simd_prefetch.d: New test.
Iain Buclaw [Sun, 23 Oct 2022 12:09:17 +0000 (14:09 +0200)]
d: Make TARGET_D_MINFO_SECTION hooks in elfos.h the language default.
Removes the last of all TARGET_D_* macro definitions in common target
headers. Now everything is either defined in the D language front-end,
or D-specific target headers.
Iain Buclaw [Mon, 17 Oct 2022 17:32:52 +0000 (19:32 +0200)]
d: Remove D-specific version definitions from target headers
This splits up the targetdm sources so that each file only handles one
target platform.
Having all logic kept in the headers means that they could become out of
sync when a new target is added (loongarch*-*-linux*) or accidentally
broken if some headers in tm_file are changed about.
gcc/ChangeLog:
* config.gcc: Split out glibc-d.o into linux-d.o, kfreebsd-d.o,
kopensolaris-d.o, and gnu-d.o. Split out cygwin-d.o from winnt-d.o.
* config/arm/linux-eabi.h (EXTRA_TARGET_D_OS_VERSIONS): Remove.
* config/gnu.h (GNU_USER_TARGET_D_OS_VERSIONS): Remove.
* config/i386/cygwin.h (EXTRA_TARGET_D_OS_VERSIONS): Remove.
* config/i386/linux-common.h (EXTRA_TARGET_D_OS_VERSIONS): Remove.
* config/i386/mingw32.h (EXTRA_TARGET_D_OS_VERSIONS): Remove.
* config/i386/t-cygming: Add cygwin-d.o.
* config/i386/winnt-d.cc (winnt_d_os_builtins): Only add
MinGW-specific version condition.
* config/kfreebsd-gnu.h (GNU_USER_TARGET_D_OS_VERSIONS): Remove.
* config/kopensolaris-gnu.h (GNU_USER_TARGET_D_OS_VERSIONS): Remove.
* config/linux-android.h (ANDROID_TARGET_D_OS_VERSIONS): Remove.
* config/linux.h (GNU_USER_TARGET_D_OS_VERSIONS): Remove.
* config/mips/linux-common.h (EXTRA_TARGET_D_OS_VERSIONS): Remove.
* config/t-glibc: Remove glibc-d.o, add gnu-d.o, kfreebsd-d.o,
kopensolaris-d.o.
* config/t-linux: Add linux-d.o.
* config/glibc-d.cc: Remove file.
* config/gnu-d.cc: New file.
* config/i386/cygwin-d.cc: New file.
* config/kfreebsd-d.cc: New file.
* config/kopensolaris-d.cc: New file.
* config/linux-d.cc: New file.
Jeff Law [Sat, 29 Oct 2022 03:33:06 +0000 (23:33 -0400)]
Fix signed vs unsigned issue in H8 port
gcc/
* config/h8300/h8300.cc (pre_incdec_with_reg): Make reg argument
an unsigned int
* config/h8300/h8300-protos.h (pre_incdec_with_reg): Adjust prototype.
Marek Polacek [Thu, 27 Oct 2022 01:15:53 +0000 (21:15 -0400)]
c++: -Wdangling-reference and system headers
I got this testcase:
auto f() -> std::optional<std::string>;
for (char c : f().value()) { }
which has a dangling reference: std::optional<T>::value returns
a reference to the contained value, but here it's the f() temporary.
We warn, which is great, but only with -Wsystem-headers, because
the function comes from a system header and warning_enabled_at used
in do_warn_dangling_reference checks diagnostic_report_warnings_p,
which in this case returned false so we didn't warn.
Fixed as below. I could also override dc_warn_system_headers so that
the warning is enabled in system headers always. With that, I found one
issue in libstdc++:
libstdc++-v3/include/bits/fs_path.h:1265:15: warning: possibly dangling reference to a temporary [-Wdangling-reference]
1265 | auto& __last = *--end();
| ^~~~~~
which looks like a true positive as well.
gcc/cp/ChangeLog:
* call.cc (maybe_warn_dangling_reference): Enable the warning in
system headers if the decl isn't in a system header.
projects / thirdparty / gcc.git / log
