We don't need to have <wchar.h> support in order to delete overloads
for inserting wide characters into narrow streams.
libstdc++-v3/ChangeLog:
PR libstdc++/98725
* include/std/ostream (operator<<(basic_ostream<char, Tr>&, wchar_t))
(operator<<(basic_ostream<char, Tr>&, const wchar_t*)): Always
define as deleted. Do not check _GLIBCXX_USE_WCHAR_T.
The wchar_t type is defined unconditionally for C++, so there is no
reason for std::wstring_convert and std::wbuffer_convert to be disabled
when <wchar.h> is not usable. It should be possible to use those class
templates with char16_t and char32_t even if wchar_t conversions don't
work.
libstdc++-v3/ChangeLog:
PR libstdc++/98725
* include/bits/locale_conv.h (wstring_convert, wbuffer_convert):
Define unconditionally. Do not check _GLIBCXX_USE_WCHAR_T.
None of these traits depend on libc support for wchar_t, so they should
be defined unconditionally. The wchar_t type is always defined in C++.
libstdc++-v3/ChangeLog:
PR libstdc++/98725
* include/c_global/cstddef [!_GLIBCXX_USE_WCHAR_T]
(__byte_operand<wchar_t>): Define specialization.
* include/std/type_traits (__make_signed<wchar_t>)
(__make_unsigned<wchar_t>): Remove redundant check for
__WCHAR_TYPE__ being defined.
* include/tr1/type_traits [!_GLIBCXX_USE_WCHAR_T]
(__is_integral_helper<wchar_t>): Likewise.
None of these vstring specializations depend on libc support for
wchar_t, so can be enabled unconditionally now that char_traits<wchar_t>
is always available.
libstdc++-v3/ChangeLog:
PR libstdc++/98725
* include/ext/rc_string_base.h [!_GLIBCXX_USE_WCHAR_T]
(__rc_string_base<wchar_t>): Define member function.
* include/ext/vstring.h [!_GLIBCXX_USE_WCHAR_T]
(hash<__gnu_cxx::__wvstring>): Define specialization.
* include/ext/vstring_fwd.h [!_GLIBCXX_USE_WCHAR_T] (__wvstring)
(__wsso_string, __wrc_string): Declare typedefs.
The wstring and wstring_view typedefs should be enabled even if
<wchar.h> isn't supported, because char_traits<wchar_t> works
unconditionally. Similarly, the std::hash specializations for wide
strings do not depend on <wchar.h> support.
Although the primary template works OK for std::char_traits<wchar_t> in
the absence of <wchar.h> support, this patch still defines it as an
explicit specialization for compatibility with declarations that expect
it to be specialized. The explicit specialization just uses the same
__gnu_cxx::char_traits base class as the primary template.
libstdc++-v3/ChangeLog:
PR libstdc++/98725
* include/bits/char_traits.h (char_traits<wchar_t>): Define
explicit specialization unconditionally.
* include/bits/basic_string.h (hash<wstring>): Define
unconditionally. Do not check _GLIBCXX_USE_WCHAR_T.
* include/bits/stringfwd.h (wstring): Likewise.
* include/debug/string (wstring): Likewise.
* include/experimental/string_view (experimental::wstring_view)
(hash<experimental::wstring_view>): Likewise.
* include/std/string (pmr::wstring, hash<pmr::wstring>):
Likewise.
* include/std/string_view (wstring_view, hash<wstring_view>):
Likewise.
This fixes a FAIL when --disable-wchar_t is used.
libstdc++-v3/ChangeLog:
* testsuite/27_io/basic_filebuf/close/81256.cc: Moved to...
* testsuite/27_io/basic_filebuf/close/wchar_t/81256.cc: ...here.
This avoids the tuple-like API for std::pair in the unordered
containers, removing some overly generic code.
The _Select1st projection can figure out the member types of a std::pair
without using decltype(std::get<0>(...)).
We don't need _Select2nd because it's only needed in
_NodeBuilder::_S_build, and that can just access the .second member of
the pair directly. The return type of that function doesn't need to be
deduced by decltype, we can just expose the __node_type typedef of the
node generator.
libstdc++-v3/ChangeLog:
* include/bits/hashtable_policy.h (_Select1st): Replace use of
std::get.
(_Select2nd): Remove.
(_NodeBuilder::_S_build): Use _NodeGenerator::__node_type
typedef instead of deducing it. Remove unnecessary piecewise
construction.
(_ReuseOrAllocNode): Make __node_type public.
(_Map_base): Adjust partial specialization to be able to extract
the mapped_type without using tuple_element.
(_Map_base::at): Define inline
* testsuite/23_containers/unordered_map/requirements/53339.cc:
Remove XFAIL.
* testsuite/23_containers/unordered_multimap/requirements/53339.cc:
Likewise.
This is a step towards restoring support for incomplete types in
unordered containers (PR 53339).
We do not need to instantiate the node type to get its value_type
member, because we know that the value type is the first template
parameter. We can deduce that template argument using a custom trait and
a partial specialization for _Hash_node. If we wanted to support custom
hash node types we could still use typename _Tp::value_type in the
primary template of that trait, but that seems unnecessary.
The other change needed is to defer a static assert at class scope, so
that it is done when the types are complete. We must have a complete
type in the destructor, so we can do it there instead.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h: Move static assertion to destructor.
* include/bits/hashtable_policy.h: Deduce value type from node
type without instantiating it.
2021-10-08 Sandra Loosemore <sandra@codesourcery.com>
PR fortran/54753
gcc/fortran/
* interface.c (gfc_compare_actual_formal): Add diagnostic
for F2018:C839. Refactor shared code and fix bugs with class
array info lookup, and extend similar diagnostic from PR94110
to also cover class types.
gcc/testsuite/
* gfortran.dg/c-interop/c535c-1.f90: Rewrite and expand.
* gfortran.dg/c-interop/c535c-2.f90: Remove xfails.
* gfortran.dg/c-interop/c535c-3.f90: Likewise.
* gfortran.dg/c-interop/c535c-4.f90: Likewise.
* gfortran.dg/PR94110.f90: Extend to cover class types.
In the PR test case SImode was used to split live range of cx on x86-64
because it was the biggest mode for this hard reg in the function. But
all 64-bits of cx contain structure members. We need always to use at least
natural mode of hard reg in splitting to fix this problem.
gcc/ChangeLog:
PR rtl-optimization/102627
* lra-constraints.c (split_reg): Use at least natural mode of hard reg.
gcc/testsuite/ChangeLog:
PR rtl-optimization/102627
* gcc.target/i386/pr102627.c: New test.
Add a #error directive to ensure that the definitions are not compiled
as C++17, which would prevent them being emitted.
libstdc++-v3/ChangeLog:
PR libstdc++/98725
* src/c++11/limits.cc: Fail if __cpp_inline_variables is
defined.
The strlen pass changes the IL as it works with the ranger. This
causes the non_null_ref code to sometimes get asked questions about new
SSA names.
Tested on x86-64 Linux.
gcc/ChangeLog:
* gimple-range-cache.cc (non_null_ref::non_null_deref_p): Grow
bitmap if needed.
The <bits/ranges_algobase.h> header doesn't need the stream and
streambuf iterators, so don't include the whole of <iterator>.
libstdc++-v3/ChangeLog:
PR libstdc++/92546
* include/bits/ranges_algobase.h: Replace <iterator> with a
subset of the headers it includes.
In g:62acc72a957b5614 I'd stopped the unroller from using
an epilogue loop in cases where the iteration count was
known to be a multiple of the unroll factor. The epilogue
and non-epilogue cases still shared this (preexisting) code
to update the edge frequencies:
basic_block exit_bb = single_pred (loop->latch);
new_exit = find_edge (exit_bb, rest);
new_exit->probability = profile_probability::always ()
.apply_scale (1, new_est_niter + 1);
[etc]
But of course (in hindsight) that only makes sense for the
epilogue case, where we've already moved the main loop's exit edge
to be a sibling of the latch edge. For the non-epilogue case,
the exit edge stays (and needs to stay) in its original position.
I don't really understand what the code is trying to do for
the epilogue case. It has:
/* Ensure that the frequencies in the loop match the new estimated
number of iterations, and change the probability of the new
exit edge. */
profile_count freq_h = loop->header->count;
profile_count freq_e = (loop_preheader_edge (loop))->count ();
if (freq_h.nonzero_p ())
{
...
scale_loop_frequencies (loop, freq_e.probability_in (freq_h));
}
Here, freq_e.probability_in (freq_h) is freq_e / freq_h, so for the
header block, this has the effect of:
new header count = freq_h * (freq_e / freq_h)
i.e. we say that the header executes exactly as often as the
preheader edge, which would only make sense if the loop never
iterates. Also, after setting the probability of the nonexit edge
(correctly) to new_est_niter / (new_est_niter + 1), the code does:
scale_bbs_frequencies (&loop->latch, 1, prob);
for this new probability. I think that only makes sense if the
nonexit edge was previously unconditional (100%). But the code
carefully preserved the probability of the original exit edge
when creating the new one.
All I'm trying to do here though is fix the mess I created
and get the probabilities right for the non-epilogue case.
Things are simpler there since we don't have to worry about
loop versioning. Hopefully the comments explain the approach.
The function's current interface implies that it can cope with
multiple exit edges and that the function only needs the iteration
count relative to one of those edges in order to work correctly.
In practice that's not the case: it assumes there is exactly one
exit edge and all current callers also ensure that the exit test
dominates the latch. I think the function is easier to follow
if we remove the implied generality.
gcc/
PR tree-optimization/102385
* predict.h (change_edge_frequency): Declare.
* predict.c (change_edge_frequency): New function.
* tree-ssa-loop-manip.h (tree_transform_and_unroll_loop): Remove
edge argument.
(tree_unroll_loop): Likewise.
* gimple-loop-jam.c (tree_loop_unroll_and_jam): Update accordingly.
* tree-predcom.c (pcom_worker::tree_predictive_commoning_loop):
Likewise.
* tree-ssa-loop-prefetch.c (loop_prefetch_arrays): Likewise.
* tree-ssa-loop-manip.c (tree_unroll_loop): Likewise.
(tree_transform_and_unroll_loop): Likewise. Use single_dom_exit
to retrieve the exit edges. Make all the old profile update code
conditional on !single_loop_p -- the case it was written for --
and use a different approach for the single-loop case.
gcc/testsuite/
* gcc.dg/pr102385.c: New test.
This is a missing piece of the C++20 <chrono> header.
It would be good to move the code into the compiled library, so that we
don't need <sstream> in <chrono>. It could also use spanstream in C++20,
to avoid memory allocations. That can be changed at a later date.
libstdc++-v3/ChangeLog:
* include/std/chrono (__detail::__units_suffix_misc): New
helper function.
(__detail::__units_suffix): Likewise.
(chrono::operator<<(basic_ostream&, const duration&)): Define.
* testsuite/20_util/duration/io.cc: New test.
The introduction of DECL_LOCAL_DECL_ALIAS and push_local_extern_decl_alias
in r11-3699-g4e62aca0e0520e4ed2532f2d8153581190621c1a broke the following
testcase. The following patch fixes it by treating similarly not just
the variable to or link clause is put on, but also its DECL_LOCAL_DECL_ALIAS
if any. If it hasn't been created yet, when it is created it will copy
attributes and therefore should get it for free, and as it is an extern,
nothing more than attributes is needed for it.
2021-10-08 Jakub Jelinek <jakub@redhat.com>
PR c++/102640
gcc/cp/
* parser.c (handle_omp_declare_target_clause): New function.
(cp_parser_omp_declare_target): Use it.
gcc/testsuite/
* c-c++-common/gomp/pr102640.c: New test.
As reported by Sunil's tester, -march=cascadelake triggers some SUBREG
non-determinacy in the generated assembler for my new tests. Fixed
by updating the regular expressions to match either the zero or sign
extended forms. I'm testing a backend patch that may help with the
underlying cause of these differences.
2021-10-08 Roger Sayle <roger@nextmovesoftware.com>
gcc/testsuite/ChangeLog
* gcc.target/i386/sse2-mmx-paddsb-2.c: Test for -128 or 128.
* gcc.target/i386/sse2-mmx-paddusb-2.c: Test for -1 or 255.
* gcc.target/i386/sse2-mmx-psubsb-2.c: Test for -128 or 128.
gcc/ChangeLog:
PR target/102464
* config/i386/i386.c (ix86_optab_supported_p):
Return true for HFmode.
* match.pd: Simplify (_Float16) ceil ((double) x) to
__builtin_ceilf16 (a) when a is _Float16 type and
direct_internal_fn_supported_p.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr102464.c: New test.
We're performing the [temp.param]/10 adjustment at parse time but not
also at substitution time.
PR c++/61355
gcc/cp/ChangeLog:
* pt.c (convert_template_argument): Perform array/function to
pointer conversion on the substituted type of an NTTP.
gcc/testsuite/ChangeLog:
* g++.old-deja/g++.pt/nontype5.C: Adjust.
* g++.dg/template/param6.C: New test.
This moves the "classic" contents of <chrono> to a new header, so that
<future>, <thread> etc. can get use durations and clocks without
calendar types, time zones, and chrono I/O.
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/std/chrono (duration, time_point, system_clock)
(steady_clock, high_resolution_clock, chrono_literals, sys_time)
(file_clock, file_time): Move to ...
* include/bits/chrono.h: New file.
* include/bits/atomic_futex.h: Include new header instead of
<chrono>.
* include/bits/atomic_timed_wait.h: Likewise.
* include/bits/fs_fwd.h: Likewise.
* include/bits/semaphore_base.h: Likewise.
* include/bits/this_thread_sleep.h: Likewise.
* include/bits/unique_lock.h: Likewise.
* include/experimental/bits/fs_fwd.h: Likewise.
* include/experimental/chrono: Likewise.
* include/experimental/io_context: Likewise.
* include/experimental/netfwd: Likewise.
* include/experimental/timer: Likewise.
* include/std/condition_variable: Likewise.
* include/std/mutex: Likewise.
* include/std/shared_mutex: Likewise.
Free up the memory held by hash tables containing CTF types and CTF variables
at the earliest. This can be done in ctfc_delete_container () as CTF debug
informtion has already been emitted.
gcc/ChangeLog:
* ctfc.c (ctfc_delete_container): Free hash table contents.
CTF is supported for C only. Currently, a warning is emitted if the -gctf
command line option is specified for a non-C frontend. This warning is also
used by the GCC testsuite framework - it skips adding -gctf to the list of
debug flags for automated testing, if CTF is not supported for the frontend.
The following warning, however, is not useful in case of LTO:
"lto1: note: CTF debug info requested, but not supported for ‘GNU GIMPLE’
frontend"
This patch disables the generation of the above warning for GNU GIMPLE.
gcc/ChangeLog:
* toplev.c (process_options): Do not warn for GNU GIMPLE.
libstdc++-v3/ChangeLog:
PR libstdc++/102377
* include/bits/atomic_wait.h (__waiter_pool_base:_S_align):
Hardcode to 64 instead of using non-constant constant.
In commit r12-4083 I tried to make the std::erase and std::erase_if
function avoid the unnecessary overhead of safe iterators. It didn't
work, for two reasons. Firstly, for the RB tree containers the
__niter_base function is a no-op (because the iterators aren't
random access) so the safe iterators were still used. Secondly, for the
cases where __niter_base did remove the safe iterator layer, there was
still unnecessary overhead to create a new safe iterator and link it to
the container.
This solves the problem by simply binding a reference to the non-debug
version of the conainer. For normal mode this is a no-op, and for debug
mode it binds a reference to the debug container's base class. That
means the rest of the function operates directly on the non-debug
container, and avoids all checking.
For std::basic_string there's no need to unwrap anything, because we use
std::basic_string directly in debug mode anyway.
libstdc++-v3/ChangeLog:
* include/bits/erase_if.h (__erase_nodes_if): Remove redundant
__niter_base calls.
* include/std/string (erase, erase_if): Likewise.
* include/std/deque (erase, erase_if): Access non-debug
container directly.
* include/std/map (erase, erase_if): Likewise.
* include/std/set (erase, erase_if): Likewise.
* include/std/unordered_map (erase, erase_if): Likewise.
* include/std/unordered_set (erase, erase_if): Likewise.
* include/std/vector (erase, erase_if): Likewise.
* include/experimental/deque (erase, erase_if): Likewise.
* include/experimental/map (erase, erase_if): Likewise.
* include/experimental/set (erase, erase_if): Likewise.
* include/experimental/unordered_map (erase, erase_if):
Likewise.
* include/experimental/unordered_set (erase, erase_if):
Likewise.
* include/experimental/vector (erase, erase_if): Likewise.
The pdecl and poff arguments were added to allow their use in
compute_objsize in builtins.c. That use has been gone for a while now
since compute_objsize does its own size estimation, so drop these
arguments to simplify code.
gcc/ChangeLog:
* tree-object-size.c (addr_object_size,
compute_builtin_object_size): Drop PDECL and POFF arguments.
(addr_object_size): Adjust calls.
* tree-object-size.h (compute_builtin_object_size): Drop PDECL
and POFF arguments.
Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
This patch introduces new RTX codes to allow the RTL passes and
backends to consistently represent high-part multiplications.
Currently, the RTL used by different backends for expanding
smul<mode>3_highpart and umul<mode>3_highpart varies greatly,
with many but not all choosing to express this something like:
(define_insn "smuldi3_highpart"
[(set (match_operand:DI 0 "nvptx_register_operand" "=R")
(truncate:DI
(lshiftrt:TI
(mult:TI (sign_extend:TI
(match_operand:DI 1 "nvptx_register_operand" "R"))
(sign_extend:TI
(match_operand:DI 2 "nvptx_register_operand" "R")))
(const_int 64))))]
""
"%.\\tmul.hi.s64\\t%0, %1, %2;")
One complication with using this "widening multiplication" representation
is that it requires an intermediate in a wider mode, making it difficult
or impossible to encode a high-part multiplication of the widest supported
integer mode. A second is that it can interfere with optimization; for
example simplify-rtx.c contains the comment:
case TRUNCATE:
/* Don't optimize (lshiftrt (mult ...)) as it would interfere
with the umulXi3_highpart patterns. */
Hopefully these problems are solved (or reduced) by introducing a
new canonical form for high-part multiplications in RTL passes.
This also simplifies insn patterns when one operand is constant.
Whilst implementing some constant folding simplifications and
compile-time evaluation of these new RTX codes, I noticed that
this functionality could also be added for the existing saturating
arithmetic RTX codes. Then likewise when documenting these new RTX
codes, I also took the opportunity to silence the @xref warnings in
invoke.texi.
2021-10-07 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
* rtl.def (SMUL_HIGHPART, UMUL_HIGHPART): New RTX codes for
representing signed and unsigned high-part multiplication resp.
* simplify-rtx.c (simplify_binary_operation_1) [SMUL_HIGHPART,
UMUL_HIGHPART]: Simplify high-part multiplications by zero.
[SS_PLUS, US_PLUS, SS_MINUS, US_MINUS, SS_MULT, US_MULT,
SS_DIV, US_DIV]: Similar simplifications for saturating
arithmetic.
(simplify_const_binary_operation) [SS_PLUS, US_PLUS, SS_MINUS,
US_MINUS, SS_MULT, US_MULT, SMUL_HIGHPART, UMUL_HIGHPART]:
Implement compile-time evaluation for constant operands.
* dwarf2out.c (mem_loc_descriptor): Skip SMUL_HIGHPART and
UMUL_HIGHPART.
* doc/rtl.texi (smul_highpart, umul_highpart): Document RTX codes.
* doc/md.texi (smul@var{m}3_highpart, umul@var{m3}_highpart):
Mention the new smul_highpart and umul_highpart RTX codes.
* doc/invoke.texi: Silence @xref "compilation" warnings.
gcc/testsuite/ChangeLog
* gcc.target/i386/sse2-mmx-paddsb-2.c: New test case.
* gcc.target/i386/sse2-mmx-paddusb-2.c: New test case.
* gcc.target/i386/sse2-mmx-psubsb-2.c: New test case.
* gcc.target/i386/sse2-mmx-psubusb-2.c: New test case.
The code handling various cases which lead to call graph edge
duplication (in order to update reference descriptions used to track
and remove no-longer needed references) has missed one important case.
When edge duplication is an effect of creating a speculative edge for
an indirect edge which carries a constant jump function which had been
created from a pass-through function when the edge caller has was
inlined into one of its callers, the reference description attached to
the function describes an edge higher up in the "inlined" clone tree
and so even the new speculative edge will. Therefore we should not
try to duplicate the reference description itself but rather just bump
the refcount of the existing one.
gcc/ChangeLog:
2021-09-22 Martin Jambor <mjambor@suse.cz>
PR ipa/102388
* ipa-prop.c (ipa_edge_args_sum_t::duplicate): Also handle the
case when the source reference description corresponds to a
referance taken in a function src->caller is inlined to.
Here we're crashing when level-lowering the variadic constraint C<Ts...>
on the template template parameter TT because tsubst_pack_expansion expects
processing_template_decl to be set during a partial substitution.
PR c++/99904
gcc/cp/ChangeLog:
* pt.c (is_compatible_template_arg): Set processing_template_decl
around tsubst_constraint_info.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-ttp4.C: New test.
An initializer-list constructor taking a non-const lvalue cannot be
called with a temporary, so the array's lifetime probably doesn't end
with the full expression. -Winit-list-lifetime should not warn for that
case.
PR c++/102482
gcc/cp/ChangeLog:
* init.c (maybe_warn_list_ctor): Do not warn for a reference to
a non-const std::initializer_list.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Winit-list5.C: New test.
gcc/ChangeLog:
2021-10-07 Jan Hubicka <hubicka@ucw.cz>
PR ipa/102581
* ipa-modref-tree.h (modref_access_node::contains_p): Handle offsets
better.
(modref_access_node::try_merge_with): Add sanity check that there
are no redundant entries in the list.
gcc/testsuite/ChangeLog:
2021-10-07 Jan Hubicka <hubicka@ucw.cz>
* g++.dg/torture/pr102581.C: New test.
I believe we need no changes to the compiler for P2316R2, seems we treat
character literals the same between preprocessor and C++ expressions,
here is a testcase that should verify it.
Note, seems the internal charset for GCC can be either UTF-8 or UTF-EBCDIC,
but I bet it is very hard (at least for me) to actually test the latter.
I'd guess one needs all system headers to be in EBCDIC and the gcc sources too.
But looking around the source, I'm a little bit worried about the UTF-EBCDIC
case.
One is:
#if '\n' == 0x0A && ' ' == 0x20 && '0' == 0x30 \
&& 'A' == 0x41 && 'a' == 0x61 && '!' == 0x21
# define HOST_CHARSET HOST_CHARSET_ASCII
#else
# if '\n' == 0x15 && ' ' == 0x40 && '0' == 0xF0 \
&& 'A' == 0xC1 && 'a' == 0x81 && '!' == 0x5A
# define HOST_CHARSET HOST_CHARSET_EBCDIC
# else
# define HOST_CHARSET HOST_CHARSET_UNKNOWN
# endif
#endif
in include/safe-ctype.h, does that mean we only support EBCDIC if -funsigned-char
and otherwise fail to build gcc? Because with -fsigned-char, '0' is -0x10
rather than 0xF0, 'A' is -0x3F rather than 0xC1 and 'a' is -0x7F rather than
0x81.
And another thing, if HOST_CHARSET == HOST_CHARSET_EBCDIC, how does the libcpp/lex.c
static const cppchar_t utf8_signifier = 0xC0;
...
if (*buffer->cur >= utf8_signifier)
{
if (_cpp_valid_utf8 (pfile, &buffer->cur, buffer->rlimit, 1 + !first,
state, &s))
return true;
}
work? Because in UTF-EBCDIC, >= 0xC0 isn't the right test for start of
multi-byte character, it is more complicated and seems _cpp_valid_utf8
assumes UTF-8 as the host charset.
2021-10-07 Jakub Jelinek <jakub@redhat.com>
PR c++/102615
* g++.dg/cpp23/charlit-encoding1.C: New testcase for C++23 P2316R2.
This makes VN not CSE .DEFERRED_INIT which confuses uninit
analysis which reports the wrong decl when facing copies
of not initialized data.
2021-10-07 Richard Biener <rguenther@suse.de>
PR tree-optimization/102608
* tree-ssa-sccvn.c (visit_stmt): Drop .DEFERRED_INIT to
varying.
Also updated my email address to the one I actually use for gcc, which
unfortunately is not the same as the one I use for glibc. Oh well...
ChangeLog:
* MAINTAINERS: Add myself to DCO section and update email
address.
gcc/c-family/ChangeLog:
* c-common.c (parse_optimize_options): Make
save_opt_decoded_options a pointer type.
gcc/ChangeLog:
* toplev.c (toplev::main): Make
save_opt_decoded_options a pointer type
* toplev.h: Likewise.
This is another case of the global_load instruction format changing in LLVM
(because they fixed a bug). The configure test is already in place to detect
what is needed.
gcc/ChangeLog:
* config/gcn/gcn-valu.md (gather<mode>_insn_2offsets<exec>): Apply
HAVE_GCN_ASM_GLOBAL_LOAD_FIXED.
(scatter<mode>_insn_2offsets<exec_scatter>): Likewise.
The option was already there, but just an alias for -msram-ecc=on. Now that
LLVM13 supports HSACOv4 and the new ELF flags I can implement the option
properly.
The "any" option is the default in order to ensure that library files work
whichever way the user wants, which means we won't need multilibs to support
the different SRAM ECC hardware configurations.
gcc/ChangeLog:
* config/gcn/gcn-hsa.h (SRAMOPT): Include the whole option string.
Adjust for new -msram-ecc=any behaviour.
(ASM_SPEC): Adjust -mxnack and -msram-ecc usage.
* config/gcn/gcn.c (output_file_start): Implement -msram-ecc=any.
* config/gcn/mkoffload.c (EF_AMDGPU_XNACK): Rename to ...
(EF_AMDGPU_XNACK_V3): ... this.
(EF_AMDGPU_SRAM_ECC): Rename to ...
(EF_AMDGPU_SRAM_ECC_V3): ... this.
(EF_AMDGPU_FEATURE_XNACK_V4): New.
(EF_AMDGPU_FEATURE_XNACK_UNSUPPORTED_V4): New.
(EF_AMDGPU_FEATURE_XNACK_ANY_V4): New.
(EF_AMDGPU_FEATURE_XNACK_OFF_V4): New.
(EF_AMDGPU_FEATURE_XNACK_ON_V4): New.
(EF_AMDGPU_FEATURE_SRAMECC_V4): New.
(EF_AMDGPU_FEATURE_SRAMECC_UNSUPPORTED_V4): New.
(EF_AMDGPU_FEATURE_SRAMECC_ANY_V4): New.
(EF_AMDGPU_FEATURE_SRAMECC_OFF_V4): New.
(EF_AMDGPU_FEATURE_SRAMECC_ON_V4): New.
(SET_XNACK_ON): New.
(SET_XNACK_OFF): New.
(TEST_XNACK): New.
(SET_SRAM_ECC_ON): New.
(SET_SRAM_ECC_ANY): New.
(SET_SRAM_ECC_OFF): New.
(TEST_SRAM_ECC_ANY): New.
(TEST_SRAM_ECC_ON): New.
(main): Implement HSACOv4 and -msram-ecc=any.
