output.printf_data.(value union) contains text[128], which has the size
of 128 bytes, sufficient for 16 uint64_t variables; hence value_u64[2]
could be extended to value_u64[6] - sufficient for all required arguments
to gomp_target_rev.  Additionally, next_output.printf_data.(msg union)
contained msg_u64 which then is no longer needed and also caused 32bit
vs 64bit alignment issues.

libgomp/
	* config/gcn/libgomp-gcn.h (struct output):
	Remove 'msg_u64' from the union, change
	value_u64[2] to value_u64[6].
	* config/gcn/target.c (GOMP_target_ext): Update accordingly.
	* plugin/plugin-gcn.c (process_reverse_offload, console_output):
	Likewise.

For systems with HAVE_DOS_BASED_FILE_SYSTEM set, only override the
pointer if the backslash pattern matches.

Output without this patch:
.../gcc/testsuite/gcc.dg/cpp/pr71681-2.c:5:10: fatal error: a/t2.h: No such file or directory

With patch applied, no output and the test case succeeds.

libcpp/ChangeLog

	* files.cc: Ensure pattern matches before use.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

My previous patch to add a sanity check to genmultilib actually
checked the number of dirnames with the number of "sets of options"
rather than the number of options, thus breaking the build on some
targets.

To avoid duplicating once more the loop that constructs the sed
patterns, this patch checks that the current dirname/osdirname is not
empty in the existing loops.

Are there targets where:
if [ "$1" != "${opt}" ]; then
is "legally" executed with an empty $1? (and thus where this patch
would incorrectly trigger an error?)

Sorry for the breakage. Tested on aarch64 by adding an option to
t-aarch64 and no corresponding dirname, and on x86_64.

gcc/ChangeLog:

	* genmultilib: Fix options and dirnames/osdirnames sanity check.

With the recent improvements to the splitting of special cases of
branch patterns on RISC-V, a dependency on an unmerged/in-discussion
change for branch-equals-zero slipped in: this allowed a non-X mode to
be presented to branch-equals-zero (where only X mode is permissible).

This addresses the issue by wrapping the ANYI operand in a paradoxical
SUBREG:X (the high bits can be safely ignored, as we we perform an
and-immediate before the branch in the pattern).

Tested against the GCC testsuite and committed as obvious.

gcc/ChangeLog:

	PR target/107786
	* config/riscv/riscv.md
	(*branch<ANYI:mode>_shiftedarith_equals_zero): Wrap ANYI
	in a subreg, as our branch instructions only supports X.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/pr107786-2.c: New test.
	* gcc.target/riscv/pr107786.c: New test.

gcc/ada/

	* gcc-interface/decl.cc (gnat_to_gnu_entity) <E_Constant>: Revert
	latest change.
	* gcc-interface/trans.cc (gnat_to_gnu) <N_Object_Declaration>:
	Tweak latest change.

If a subtype has a Size attribute value different than the size of its
ancestor, then the Packed Array Type can't be shared and a new one must
be created.

gcc/ada/

	* exp_pakd.adb (Create_Packed_Array_Impl_Type): Do not share PAT
	if sizes of types differ.

gcc/ada/

	* doc/gnat_rm/implementation_defined_pragmas.rst: Restore
	alphabetical ordering.
	* gnat_rm.texi: Regenerate.
	* gnat_ugn.texi: Regenerate.

For an array subtype, being definite is the same as being constrained.

gcc/ada/

	* sem_util.adb (Needs_Secondary_Stack): Test Is_Constrained
	directly instead of Is_Definite_Subtype for an array subtype.

In some cases, compilation of a function with a limited class-wide result
type could fail with an internal error if a Sequential
Partition_Elaboration_Policy is specified. To prevent this, we want specifying
a Sequential Partition_Elaboration_Policy to have the side effect of
imposing a No_Task_Hierarchy restriction. But doing that in a straightforward
way leads to problems with incorrectly accepting violations of H.6(6). So
a new restriction, No_Task_Hierarchy_Implicit, is introduced.

gcc/ada/

	* libgnat/s-rident.ads: Define a new restriction,
	No_Task_Hierarchy_Implicit. This is like the No_Task_Hierarchy
	restriction, but with the difference that setting this restriction
	does not mean the H.6(6) post-compilation check is satisified.
	* exp_ch6.adb (Add_Task_Actuals_To_Build_In_Place_Call): If it is
	known that the function result cannot have tasks, then pass in a
	null literal for the activation chain actual parameter. This
	avoids generating a reference to an entity that
	Build_Activation_Chain_Entity may have chosen not to generate a
	declaration for.
	* gnatbind.adb (List_Applicable_Restrictions): Do not list the
	No_Task_Hierarchy_Implicit restriction.
	* restrict.adb: Special treatment for the
	No_Task_Hierarchy_Implicit restriction in functions
	Get_Restriction_Id and Restriction_Active. The former is needed to
	disallow the (unlikely) case that a user tries to explicitly
	reference the No_Task_Hierarchy_Implicit restriction.
	* sem_prag.adb (Analyze_Pragma): If a Sequential
	Partition_Elaboration_Policy is specified (and the
	No_Task_Hierarchy restriction is not already enabled), then enable
	the No_Task_Hierarchy_Implicit restriction.

This reuses a local constant more consistently, removes a duplicate of this
local constant, renames local variables, alphabetizes declarations, makes a
few consistency tweaks and adjusts a couple of comments.

No functional changes.

gcc/ada/

	* exp_ch3.adb (Expand_N_Object_Declaration): Use Typ local
	constant throughout, remove Ret_Obj_Typ local constant, rename
	Ref_Type into Acc_Typ in a couple of places, remove a useless call
	to Set_Etype, use a consistent checks suppression scheme, adjust
	comments for the sake of consistencty and alphabetize some local
	declarations.
	* exp_ch6.adb (Expand_Simple_Function_Return): Remove a couple of
	redundant local constants.

Two issues. First, the two procedures
Ada.Strings.Text_Buffers.Output_Mapping.[Wide_]Wide_Put each correctly
call Encode, but that call was missing from the corresponding Put procedure.
Second, if a record type contains an array-valued Data component as well as
both a Max_Length and Current_Length component, then the slice
Data (Current_Length + 1 .. Max_Length) should usually be treated like
uninitialized data. It should not participate in things like equality
comparisons. In particular, it should not participate in 'Image results.
To accomplish this, such a type usually ought to have a Put_Image aspect
specification. This Put_Image aspect specification was missing for the
three Super_String types declared in the
Ada.Strings.[Wide_[Wide_]]Superbounded packages.

gcc/ada/
	* libgnat/a-sttebu.adb (Put): Add missing call to Encode.
	* libgnat/a-strsup.ads: Declare new Put_Image procedure and add
	Put_Image aspect specification for type Super_String.
	* libgnat/a-strsup.adb (Put_Image): New procedure.
	* libgnat/a-stwisu.ads: Declare new Put_Image procedure and add
	Put_Image aspect specification for type Super_String.
	* libgnat/a-stwisu.adb (Put_Image): New procedure.
	* libgnat/a-stzsup.ads: Declare new Put_Image procedure and add
	Put_Image aspect specification for type Super_String.
	* libgnat/a-stzsup.adb (Put_Image): New procedure.

CodePeer builds with assertions enabled started failing when this
validation was introduced. We temporarily disable this validation for
CodePeer in order to buy time before fixing the underlying issue.

gcc/ada/

	* frontend.adb (Frontend): Disable subprogram call validation.

This patch moves warning switches from Opt into Warnsw, fixes some minor
discrepancies, and cleans up the code.

No change in behavior.

gcc/ada/

	* warnsw.ads, warnsw.adb: Move warning flags here from package
	Opt. Rename Warning_Record to be Warnings_State. Use an array
	instead of a record; this simplifies the code. Add renamings of
	all the array components for easy reference outside this package.
	Pass the "Family" to Set_Warning_Switch. Use more table-driven
	code. Misc cleanup and comment fixes.
	* opt.ads: Move warning switches to Warnsw.
	* gnat1drv.adb
	(Adjust_Global_Switches): Expanded names needed.
	* inline.ads: Rename Warning_Record to be Warnings_State.
	* sem_ch12.adb: Likewise.
	* sem_prag.adb: Use new Set_Warning_Switch.
	* contracts.adb, errout.adb, exp_aggr.adb, exp_ch11.adb: Adjust
	imports for move to Warnsw.
	* exp_ch5.adb, exp_prag.adb, exp_util.adb, frontend.adb: Likewise.
	* layout.adb, lib-xref.adb, restrict.adb, scn.adb, sem_aggr.adb:
	Likewise.
	* sem_attr.adb, sem_case.adb, sem_ch10.adb, sem_ch11.adb:
	Likewise.
	* sem_ch13.adb, sem_ch3.adb, sem_ch4.adb, sem_ch5.adb: Likewise.
	* sem_ch6.adb, sem_ch7.adb, sem_ch8.adb, sem_elab.adb: Likewise.
	* sem_eval.adb, sem_res.adb, sem_util.adb, sem_warn.adb: Likewise.
	* switch-c.adb: Likewise.

The -gnatw.h option enables warnings about "gaps" in record layout
specifications. In the case of a "partial" layout specification, where the
locations of some components are left unspecified, the resulting warnings
may be incomplete or incorrect. Document this implementation limitation.

gcc/ada/

	* doc/gnat_ugn/building_executable_programs_with_gnat.rst: Improve
	the description of how the -gnatw.h switch interacts with
	"partial" record layout specifications (i.e., specifications where
	the locations of some components are left unspecified).
	* gnat_ugn.texi: Regenerate.

Only confirming Size must be supported for aliased object of elementary
type (see RM 13.1 in the "Implementation Advice").

   -- size is 1-byte
   type Y is range 0 .. 20;
   type Ay is access all Y;

   -- Var size is 8-bytes
   Var : aliased Y := 5 with Size => 64;

   --  JP.all is a 1-byte reference to an 8-bytes objects.
   JP : Ay := Var'Access;

The above JP.all references the first byte of the 8-byte Var object,
which is, for example, not correct on little-endian systems.

This change rejects nonconfirming Size attribute on such objects
instead of miscompiling it.

gcc/ada/

	* sem_ch13.adb (Check_One_Attr): produce error when Size attribute
	used on aliased object of elementary types with nonconfirming
	value.

Before this patch, gnatmake's parser for adc files failed to ignore
semicolons located inside comments. This patch fixes that behavior.

gcc/ada/

	* sfn_scan.adb (Scan_SFN_Pragmas): Improve handling of comments.

Before this patch, with clauses placed in declarative sections were
interpreted by the compiler as incorrect aspect specifications, which
led to confusing error messages.

This patch makes it so more syntax errors involving the with keyword
are diagnosed as intended with clauses instead of aspect
specifications.

gcc/ada/

	* par-ch3.adb (P_Declarative_Item): Tweak handling of with keyword.

While reporting PR107748 (where is a problem with non-uglified names,
but I've left it out because it needs fixing anyway), I've noticed
various spots where identifiers in *intrin.h headers weren't uglified.
The following patch fixed those that are related to unions (I've grepped
for [a-zA-Z]\.[a-zA-Z] spots).
The reason we need those to be uglified is the same as why the arguments
of the inlines are __ prefixed and most of automatic vars in the inlines
- say a, v or u aren't part of implementation namespace and so users could
 #define u whatever->something
 #include <x86intrin.h>
and it should still work, as long as u is not e.g. one of the names
of the functions/macros the header provides (_mm* etc.).

2022-11-21  Jakub Jelinek  <jakub@redhat.com>

	PR target/107748
	* config/i386/avx512fp16intrin.h (_mm512_castph512_ph128,
	_mm512_castph512_ph256, _mm512_castph128_ph512,
	_mm512_castph256_ph512, _mm512_set1_pch): Uglify names of local
	variables and union members.
	* config/i386/avx512fp16vlintrin.h (_mm256_castph256_ph128,
	_mm256_castph128_ph256, _mm256_set1_pch, _mm_set1_pch): Likewise.
	* config/i386/smmintrin.h (_mm_extract_ps): Likewise.

When a list of dirnames is provided to genmultilib, its length is
expected to match the number of options.  If this is not the case, the
build fails later for reasons not obviously related to this mistake.
This patch adds a sanity check to help diagnose such cases.

Tested by adding an option to t-aarch64 and no corresponding dirname,
with both bash and dash.

v2: do not use arrays (bash feature).

OK for trunk?

gcc/ChangeLog:

	* genmultilib: Add sanity check.

Unlike most other machine attributes, this one does not work in Ada because,
while it applies to pointer-to-function types, it is explicitly marked as
requiring declarations in the implementation.

Now, in Ada, machine attributes are specified like this:

  type Non_Secure is access procedure;
  pragma Machine_Attribute (Non_Secure, "cmse_nonsecure_call");

i.e. not attached to the declaration of Non_Secure.

The change extends the support to Ada by also accepting pointer-to-function
types in the handler.

gcc/
	* config/arm/arm.cc (arm_attribute_table) <cmse_nonsecure_call>:
	Change decl_required field to false.
	(arm_handle_cmse_nonsecure_call): Deal with a TYPE node.

gcc/testsuite/
	* gnat.dg/machine_attr2.ads, gnat.dg/machine_attr2.adb: New test.

This reverts commit 0275ff20.

libcpp/ChangeLog:

	* config.in: Re-configure.

libstdc++-v3/ChangeLog:

	* src/experimental/Makefile.in: Re-configure.

This another one of these ICE after error issues with the
gimplifier and a fallout from r12-3278-g823685221de986af.
The problem here is gimplify_modify_expr does not
check if either from or to was an error operand.
This adds the check and fixes the ICE.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

gcc/ChangeLog:

	* gimplify.cc (gimplify_modify_expr): If
	either *from_p or *to_p were error_operand
	return early.

gcc/testsuite/ChangeLog:

	* gcc.dg/redecl-23.c: New test.
	* gcc.dg/redecl-24.c: New test.
	* gcc.dg/redecl-25.c: New test.

This should fix incorrect error when call those builtin with
-mavxneconvert and w/o -mavx512bf16 -mavx512vl.

gcc/ChangeLog:

	* config/i386/i386-builtins.cc (def_builtin): Handle "shared"
	avx512bf16vl-avxneconvert builtins.

gcc/testsuite/ChangeLog:

	* gcc.target/i386/avxneconvert-1.c: New test.

Those qualifications are needed in _GLIBCXX_INLINE_VERSION mode because in <cctype>
symbols are not put in versioned namespace.

libstdc++-v3/ChangeLog

	* include/std/format: Add std qualification on isxdigit calls.

We already cache the overall normal form of a declaration's constraints
(under the assumption that it can't change over the translation unit).
But if we have something like

  template<class T> concept complicated = /* ... */;
  template<class T> void f() requires complicated<T> && /* ... */;
  template<class T> void g() requires complicated<T> && /* ... */;

then despite this high-level caching we'd still redundantly have to
expand the concept-id complicated<T> twice, once during normalization of
f's constraints and again during normalization of g's.  Ideally, we'd
reuse the previously computed normal form of complicated<T> the second
time around.

To that end this patch introduces an intermediate layer of caching
during constraint normalization -- caching of the normal form of a
concept-id -- that sits between our high-level caching of the overall
normal form of a declaration's constraints and our low-level caching of
each individual atomic constraint.

It turns out this caching generalizes normalize_concept_check's caching
of the normal form of a concept definition (which is equivalent to the
normal form of the concept-id C<gtargs> where gtargs is C's generic
arguments) so this patch unifies the caching accordingly.

gcc/cp/ChangeLog:

	* constraint.cc (struct norm_entry): Define.
	(struct norm_hasher): Define.
	(norm_cache): Define.
	(normalize_concept_check): Add function comment.  Cache the
	the normal form of the substituted concept-id.  Canonicalize
	generic arguments as NULL_TREE.  Don't coerce arguments unless
	they were substituted.
	(normalize_concept_definition): Simplify.  Use norm_cache
	instead of normalized_map.

The only practical difference between coerce_innermost_template_parms
and the main function coerce_template_parms is that the former accepts
a potentially multi-level parameter list and returns an argument vector
of the same depth, whereas the latter accepts only a single level of
parameters and only returns only a single level of arguments.  Both
functions accept a multi-level argument vector.

In light of this, it seems more natural to just overload the behavior of
the main function according to whether the given parameter list is
multi-level or not.  And it turns out we can assume the given parms and
args have the same depth in the multi-level case, which simplifies the
overloading logic.

Besides the simplification benefit, another benefit of this unification
is that it avoids an extra copy of a multi-level args since now we can
return new_args directly from c_t_p.  (And because of this, we need to
turn new_inner_args into a reference so that overwriting it also updates
new_args.)

gcc/cp/ChangeLog:

	* pt.cc (coerce_template_parms): Salvage part of the function
	comment from c_innermost_t_p.  Handle parms being a full
	template parameter list.
	(coerce_innermost_template_parms): Remove.
	(lookup_template_class): Use c_t_p instead of c_innermost_t_p.
	(finish_template_variable): Likewise.
	(tsubst_decl): Likewise.
	(instantiate_alias_template): Likewise.

As the following testcase shows, the swap_rtx_condition function
in reg-stack can result in different code generation between -g and -g0.
The function is doing the changes as it goes, so does analysis and
changes together, which makes it harder to deal with DEBUG_INSNs,
where normally analysis phase ignores them and the later phase
doesn't.
swap_rtx_condition walks instructions two different ways, one is
using next_flags_user function which stops on non-call instructions
that mention the flags register, and the other is a loop on fnstsw
where it stops on instructions mentioning it and tries to find
sahf instruction that uses it (in both cases calls stop it and so
does end of basic block).
Now both of these currently stop on DEBUG_INSNs that mention
the flags register resp. the fnstsw result register.
On success the function recurses on next flags user instruction
if still live and if the recursion failed, reverts the changes
it did too and fails.
If it were just for the next_flags_user case, the fix could be
just not doing
      INSN_CODE (insn) = -1;
      if (recog_memoized (insn) == -1)
        fail = 1;
on DEBUG_INSNs (assuming all changes to those are fine),
swap_rtx_condition_1 just changes one comparison to a different
one.  But due to the possibility of fnstsw result being used
in theory before sahf in some DEBUG_INSNs, this patch takes
a different approach.  swap_rtx_condition has now a new argument
and two modes.  The first mode is when debug_seen is >= 0, in this
case both next_flags_user and the loop for fnstsw -> sahf will
ignore but note DEBUG_INSNs (that mention flags register or fnstsw
result).  If no such DEBUG_INSN is found during the whole call
including recursive invocations (so e.g. for -g0 but probably most
often for -g as well), it behaves as before, if it returns true
all the changes are done and nothing further needs to be done later.
If any DEBUG_INSNs are seen along the way, even when returning success
all the changes are reverted, so it just reports that the function
would be successful if DEBUG_INSNs were ignored.
In this case, compare_for_stack_reg needs to call it again in
debug_seen = -1 mode, which tells the function to update everything
including DEBUG_INSNs.  For the fnstsw -> sahf case which I hope
will be very rare I just reset the DEBUG_INSNs, I don't really
know how to express it easily otherwise.  For the rest
swap_rtx_condition_1 is done even on the DEBUG_INSNs.

2022-11-20  Jakub Jelinek  <jakub@redhat.com>

	PR target/107183
	* reg-stack.cc (next_flags_user): Add DEBUG_SEEN argument.
	If >= 0 and a DEBUG_INSN would be otherwise returned, set
	DEBUG_SEEN to 1 and ignore it.
	(swap_rtx_condition): Add DEBUG_SEEN argument.  In >= 0
	mode only set DEBUG_SEEN to 1 if problematic DEBUG_ISNSs
	were seen and revert all changes on success in that case.
	Don't try to recog_memoized DEBUG_INSNs.
	(compare_for_stack_reg): Adjust swap_rtx_condition caller.
	If it returns true and debug_seen is 1, call swap_rtx_condition
	again with debug_seen -1.

	* gcc.dg/ubsan/pr107183.c: New test.

contrib/ChangeLog:

	* gcc-changelog/git_commit.py: Temporarily disable
	check_line.start.

gcc/
	PR other/104044
	* config/mn10300/mn10300.cc (mn10300_print_operand): Remove
	extraneous semicolon.
	* config/nvptx/nvptx.cc (nvptx_goacc_reduction_fini): Likewise.

gcc/jit/
	PR other/104044
	* jit-playback.cc (playback::lvale::mark_addressable): Remove
	extraeous semicolon

The tester started tripping this on s390-linux-gnu:

Tests that now fail, but worked before (19 tests):

gcc.dg/pr96542.c scan-tree-dump-times evrp "254" 2

The problem is we search for "254" in the dump file.  The dump file contains
UIDs for function declarations.  So changes in the number of predefined DECL
nodes can make the test pass or file depending on whether or not a decl with
a UID containing "254" shows up.  Like this:

;; Function foo (foo, funcdef_no=0, decl_uid=2542, cgraph_uid=1, symbol_order=0)

ISTM the test wants to look for a "return 254" rather than just "254".
I added a change for that to the tester.  Naturally that fixed the test on
s390 and the dozen or so targets I tested didn't show any regressions.

gcc/testsuite
	* gcc.dg/pr96542.c: Avoid falsely matching DECL_UIDs with
	the number 254 in them.

This makes all the [iterator.range] functions always-inline, except the
ones that construct a std::reverse_iterator, as they do a little more
work. They could probably be made always_inline too though, and maybe
the std::reverse_iterator constructor too.

This means that even for -O0 these functions have no runtime overhead
compared with calling a member of the container, or performing pointer
arithmetic for arrays.

libstdc++-v3/ChangeLog:

	* include/bits/range_access.h: Add always_inline attribute to
	trivial functions.

Since we use C++11 by default now, we can
use constexpr for some const decls in tree-core.h.

This patch does that and it allows for better optimizations
of GCC code with checking enabled and without LTO.

For an example generic-match.cc compiling is speed up due
to the less number of basic blocks and less debugging info
produced. I did not check the speed of compiling the same source
but rather the speed of compiling the old vs new sources here
(but with the same compiler base).

The small slow down in the parsing of the arrays in each TU
is migrated by a speed up in how much code/debugging info
is produced in the end.

Note I looked at generic-match.cc since it is one of the
compiling sources which causes parallel building to stall and
I wanted to speed it up.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

gcc/ChangeLog:

	PR middle-end/14840
	* tree-core.h (tree_code_type): Constexprify
	by including all-tree.def.
	(tree_code_length): Likewise.
	* tree.cc (tree_code_type): Remove.
	(tree_code_length): Remove.

libstdc++-v3/ChangeLog:

	* include/std/format: Fix -Wsign-compare warnings.

This fixes a Doxygen warning about a mismatched parameter name. The
standard uses 'r' here, like the Doxygen comment, so use '__r' instead
of '__e'.

libstdc++-v3/ChangeLog:

	* include/bits/ptr_traits.h (pointer_traits::pointer_to): Rename
	parameter.

libstdc++-v3/ChangeLog:

	PR libstdc++/107649
	* include/std/complex (__complex_proj): Fix requires-clause.

A recent nvptx-tools change: commit 886a95faf66bf66a82fc0fe7d2a9fd9e9fec2820
"ld: Don't search for input files in '-L'directories" (of
<https://github.com/MentorEmbedded/nvptx-tools/pull/38>
"Match standard 'ld' "search" behavior") in GCC/nvptx target testing
generally causes linking to fail with:

    error opening crt0.o
    collect2: error: ld returned 1 exit status
    compiler exited with status 1

Indeed per GCC '-v' output, there is an undecorated 'crt0.o' on the linker
('collect2') command line:

     [...]/build-gcc/./gcc/collect2 -o [...] crt0.o [...]

This is due to:

    gcc/config/nvptx/nvptx.h:#define STARTFILE_SPEC "%{mmainkernel:crt0.o}"

..., and the fix, as used by numerous other GCC targets, is to instead use
'crt0.o%s'; for '%s' means, per 'gcc/gcc.cc', "The Specs Language":

     %s     current argument is the name of a library or startup file of some sort.
            Search for that file in a standard list of directories
            and substitute the full name found.

With that, we get the expected path to 'crt0.o'.

	gcc/
	* config/nvptx/nvptx.h (STARTFILE_SPEC): Fix 'crt0.o' for
	'-mmainkernel'.

r7-912 copied (parts of) the valgrind annotation checks from gcc
to libcpp. The above copies the missing pieces to libcpp to diagnose
when libcpp is configured with --enable-valgrind-annotations but
valgrind is not installed.

libcpp/ChangeLog:

	PR preprocessor/107691
	* configure.ac: Add valgrind header checks.
	* configure: Regenerate.