PR analyzer/107711 seems to be a bug in how named constants are looked up
by the analyzer in the C frontend.

To help debug this, this patch extends -fdump-analyzer and
-fdump-analyzer-stderr so that they dump this part of the analyzer's
startup.

gcc/analyzer/ChangeLog:
	PR analyzer/107711
	* analyzer-language.cc: Include "diagnostic.h".
	(maybe_stash_named_constant): Add logger param and use it to log
	the name being looked up, and the result.
	(stash_named_constants): New, splitting out from...
	(on_finish_translation_unit): ...this function.  Call
	get_or_create_logfile and use the result to create a logger
	instance, passing it to stash_named_constants.
	* analyzer.h (get_or_create_any_logfile): New decl.
	* engine.cc (dump_fout, owns_dump_fout): New globals, split out
	from run_checkers.
	(get_or_create_any_logfile): New function, split out from...
	(run_checkers): ...here, so that the logfile can be opened by
	on_finish_translation_unit.  Clear the globals when closing the
	dump file.

gcc/testsuite/ChangeLog:
	PR analyzer/107711
	* gcc.dg/analyzer/fdump-analyzer-1.c: New test.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

gcc/fortran/ChangeLog:

	PR fortran/107707
	* interface.cc (gfc_compare_actual_formal): Check that we actually
	have integer values before asking gmp_* to use them.

gcc/testsuite/ChangeLog:

	PR fortran/107707
	* gfortran.dg/pr107707.f90: New test.

This patch implements C++23 P2448, which lifts more restrictions on the
constexpr keyword.  It's effectively going the way of being just a hint
(hello, inline!).

This gist is relatively simple: in C++23, a constexpr function's return
type/parameter type doesn't have to be a literal type; and you can have
a constexpr function for which no invocation satisfies the requirements
of a core constant expression.  For example,

  void f(int& i); // not constexpr

  constexpr void g(int& i) {
    f(i); // unconditionally calls a non-constexpr function
  }

is now OK, even though there isn't an invocation of 'g' that would be
a constant expression.  Maybe 'f' will be made constexpr soon, or maybe
this depends on the version of C++ used, and similar.  The patch is
unfortunately not that trivial.  The important bit is to use the new
require_potential_rvalue_constant_expression_fncheck in
maybe_save_constexpr_fundef (and where appropriate).  It has a new flag
that says that we're checking the body of a constexpr function, and in
that case it's OK to find constructs that aren't a constant expression.

Since it's useful to be able to check for problematic constructs even
in C++23, this patch implements a new warning, -Winvalid-constexpr,
which is a pedwarn turned on by default in C++20 and earlier, and which
can be turned on in C++23 as well, in which case it's an ordinary warning.
This I implemented by using the new function constexpr_error, used in
p_c_e_1 and friends.  (In some cases I believe fundef_p will be always
false (= hard error), but it made sense to me to be consistent and use
constexpr_error throughout p_c_e_1.)

While working on this I think I found a bug, see constexpr-nonlit15.C
and <https://gcc.gnu.org/PR107598>.  This patch doesn't address that.

This patch includes changes to diagnose the problem if the user doesn't
use -Winvalid-constexpr and calls a constexpr function that in fact isn't
constexpr-ready yet: maybe_save_constexpr_fundef registers the function
if warn_invalid_constexpr is 0 and explain_invalid_constexpr_fn then
gives the diagnostic.

	PR c++/106649

gcc/c-family/ChangeLog:

	* c-cppbuiltin.cc (c_cpp_builtins): Update value of __cpp_constexpr for
	C++23.
	* c-opts.cc (c_common_post_options): Set warn_invalid_constexpr
	depending on cxx_dialect.
	* c.opt (Winvalid-constexpr): New option.

gcc/cp/ChangeLog:

	* constexpr.cc (constexpr_error): New function.
	(is_valid_constexpr_fn): Use constexpr_error.
	(maybe_save_constexpr_fundef): Call
	require_potential_rvalue_constant_expression_fncheck rather than
	require_potential_rvalue_constant_expression.  Register the
	function if -Wno-invalid-constexpr was specified.
	(explain_invalid_constexpr_fn): Don't return early if a function marked
	'constexpr' that isn't actually a constant expression was called.
	(non_const_var_error): Add a bool parameter.  Use constexpr_error.
	(inline_asm_in_constexpr_error): Likewise.
	(cxx_eval_constant_expression): Adjust calls to non_const_var_error
	and inline_asm_in_constexpr_error.
	(potential_constant_expression_1): Add a bool parameter.  Use
	constexpr_error.
	(require_potential_rvalue_constant_expression_fncheck): New function.
	* cp-tree.h (require_potential_rvalue_constant_expression_fncheck):
	Declare.
	* method.cc (struct comp_info): Call
	require_potential_rvalue_constant_expression_fncheck rather than
	require_potential_rvalue_constant_expression.

gcc/ChangeLog:

	* doc/invoke.texi: Document -Winvalid-constexpr.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/constexpr-ctor2.C: Expect an error in c++20_down only.
	* g++.dg/cpp0x/constexpr-default-ctor.C: Likewise.
	* g++.dg/cpp0x/constexpr-diag3.C: Likewise.
	* g++.dg/cpp0x/constexpr-ex1.C: Likewise.
	* g++.dg/cpp0x/constexpr-friend.C: Likewise.
	* g++.dg/cpp0x/constexpr-generated1.C: Likewise.
	* g++.dg/cpp0x/constexpr-ice5.C: Likewise.
	* g++.dg/cpp0x/constexpr-ice6.C: Likewise.
	* g++.dg/cpp0x/constexpr-memfn1.C: Likewise.
	* g++.dg/cpp0x/constexpr-neg2.C: Likewise.
	* g++.dg/cpp0x/constexpr-non-const-arg.C: Likewise.
	* g++.dg/cpp0x/constexpr-reinterpret1.C: Likewise.
	* g++.dg/cpp0x/pr65327.C: Likewise.
	* g++.dg/cpp1y/constexpr-105050.C: Likewise.
	* g++.dg/cpp1y/constexpr-89285-2.C: Likewise.
	* g++.dg/cpp1y/constexpr-89285.C: Likewise.
	* g++.dg/cpp1y/constexpr-89785-2.C: Likewise.
	* g++.dg/cpp1y/constexpr-neg1.C: Likewise.
	* g++.dg/cpp1y/constexpr-nsdmi7b.C: Likewise.
	* g++.dg/cpp1y/constexpr-throw.C: Likewise.
	* g++.dg/cpp23/constexpr-nonlit3.C: Remove dg-error.
	* g++.dg/cpp23/constexpr-nonlit6.C: Call the test functions.
	* g++.dg/cpp23/feat-cxx2b.C: Adjust the expected value of
	__cpp_constexpr.
	* g++.dg/cpp2a/consteval3.C: Remove dg-error.
	* g++.dg/cpp2a/constexpr-new7.C: Expect an error in c++20_down only.
	* g++.dg/cpp2a/constexpr-try5.C: Remove dg-error.
	* g++.dg/cpp2a/spaceship-constexpr1.C: Expect an error in c++20_down
	only.
	* g++.dg/cpp2a/spaceship-eq3.C: Likewise.
	* g++.dg/diagnostic/constexpr1.C: Remove dg-error.
	* g++.dg/gomp/pr79664.C: Use -Winvalid-constexpr -pedantic-errors.
	* g++.dg/ubsan/vptr-4.C: Likewise.
	* g++.dg/cpp23/constexpr-nonlit10.C: New test.
	* g++.dg/cpp23/constexpr-nonlit11.C: New test.
	* g++.dg/cpp23/constexpr-nonlit12.C: New test.
	* g++.dg/cpp23/constexpr-nonlit13.C: New test.
	* g++.dg/cpp23/constexpr-nonlit14.C: New test.
	* g++.dg/cpp23/constexpr-nonlit15.C: New test.
	* g++.dg/cpp23/constexpr-nonlit16.C: New test.
	* g++.dg/cpp23/constexpr-nonlit8.C: New test.
	* g++.dg/cpp23/constexpr-nonlit9.C: New test.

This is only a partial fix for the PR.

libstdc++-v3/ChangeLog:

	PR libstdc++/107720
	* include/std/format (__format::_Arg_t): Fix typo in enumerator
	name.
	(_Arg_value::_S_get): Fix missing semi-colons.

We can use an array instead of a std::vector, and we can avoid the
binary search for the common case of a time point after the most recent
leap second. On one system where I tested this, utc_clock::now() now
takes about 16ns instead of 31ns.

libstdc++-v3/ChangeLog:

	* include/std/chrono (get_leap_second_info): Optimize.

Clang doesn't define __builtin_toupper, so use std::toupper.

Also add some (not actually required since C++20) typename keywords to
help Clang versions up to and including 15.

libstdc++-v3/ChangeLog:

	PR libstdc++/107712
	* include/std/format (__format::__formatter_int::format): Use
	std::toupper when __builtin_toupper isn't available.
	(basic_format_arg::handle): Add 'typename'.
	* include/std/complex (complex<T>): Add 'typename'.

This restricts std::format support for _Float128 (and __float128) to
targets where glibc provides __strfromf128 and so can give correct
output.

libstdc++-v3/ChangeLog:

	* include/std/format [__FLT128_DIG__] (_GLIBCXX_FORMAT_F128):
	Only support formatting _Float128 when glibc provides the
	functionality needed for accurate std::to_chars.

gcc/fortran/ChangeLog:

	PR fortran/107681
	* resolve.cc (resolve_fl_var_and_proc): Prevent NULL pointer
	dereference with reference to bad CLASS variable.

gcc/testsuite/ChangeLog:

	PR fortran/107681
	* gfortran.dg/pr107681.f90: New test.

gcc/fortran/ChangeLog:

	PR fortran/107680
	* arith.cc (arith_power): Check that operands are properly converted
	before attempting to simplify.

gcc/testsuite/ChangeLog:

	PR fortran/107680
	* gfortran.dg/pr107680.f90: New test.

We avoid reassociating "(~(a >> BIT_NO)) & 1" into "((~a) >> BIT_NO) & 1"
by splitting it into a zero-extraction (bext) and an xori.  This both
avoids burning a register on a temporary and generates a sequence that
clearly captures 'extract bit, then invert bit'.

This change improves the previously generated
    srl   a0,a0,a1
    not	  a0,a0
    andi  a0,a0,1
into
    bext  a0,a0,a1
    xori  a0,a0,1

Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>

gcc/ChangeLog:

	* config/riscv/bitmanip.md: Add split covering
	"(a & (1 << BIT_NO)) ? 0 : 1".

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/zbs-bext.c: Add testcases.
	* gcc.target/riscv/zbs-bexti.c: Add testcases.

For a straightforward application of bext for the following function
  long bext64(long a, char bitno)
  {
    return (a & (1UL << bitno)) ? 0 : -1;
  }
we generate
	srl	a0,a0,a1	# 7	[c=4 l=4]  lshrdi3
	andi	a0,a0,1	# 8	[c=4 l=4]  anddi3/1
	addi	a0,a0,-1	# 14	[c=4 l=4]  adddi3/1
due to the following failed match at combine time:
  (set (reg:DI 82)
       (zero_extract:DI (reg:DI 83)
            (const_int 1 [0x1])
            (reg:DI 84)))

The existing pattern for bext requires the 3rd argument to
zero_extract to be a QImode register wrapped in a zero_extension.
This adds an additional pattern that allows an Xmode argument.

With this change, the testcase compiles to
	bext	a0,a0,a1	# 8	[c=4 l=4]  *bextdi
	addi	a0,a0,-1	# 14	[c=4 l=4]  adddi3/1

gcc/ChangeLog:

	* config/riscv/bitmanip.md (*bext<mode>): Add an additional
	pattern that allows the 3rd argument to zero_extract to be
	an Xmode register operand.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/zbs-bext.c: Add testcases.
	* gcc.target/riscv/zbs-bexti.c: Add testcases.

In commit r13-2619-g34b9a03353d3fd, [transform] was applied to all
invocations of gcov, for both out-of-tree and in-tree testing.
For in-tree cross builds, this means gcov was called as
"/path/to/gccobj/gcc/target-tuple-gcov" gcov-pr94029.c which is
incorrect, as it's there "/path/to/gccobj/gcc/gcov" until it's
installed.  This caused a testsuite failure, like:

Running /x/gcc/gcc/testsuite/gcc.misc-tests/gcov.exp ...
FAIL: gcc.misc-tests/gcov-pr94029.c gcov failed: spawn failed

To avoid cumbersome conditionals, use a dedicated new helper function.

gcc/testsuite:
	* lib/gcc-dg.exp (gcc-transform-out-of-tree): New proc.
	* g++.dg/gcov/gcov.exp, gcc.misc-tests/gcov.exp: Call
	gcc-transform-out-of-tree instead of transform.

The following propely restricts the bitfield access to integral types
when we look through VEC_UNPACK with the intent to emit a widening
conversion.

	PR tree-optimization/107686
	* tree-ssa-forwprop.cc (optimize_vector_load): Restrict
	VEC_UNPACK support to integral typed bitfield refs.

	* gcc.dg/pr107686.c: New testcase.

When the frontend clobbers a parameter and that parameter gets
rewritten into SSA then we ICE because we didn't expect this.  Avoid
using the parameter decl to create a SSA default def in this case.

	PR middle-end/107679
	* tree-into-ssa.cc (maybe_register_def): Use new temporary if
	we require an uninitialized value for a parameter decl.

	* gfortran.dg/pr107679.f90: New testcase.

This test of leap second handling is taken from the C++20 standard.

libstdc++-v3/ChangeLog:

	* testsuite/std/time/clock/utc/1.cc: Check handling across leap
	second insertion.

libatomic/ChangeLog:

	* Makefile.in: Re-generate.

When linking with a static library, the linker seems to discard a
constituent .o object (including its global initializers) if nothing
defined in the object is referenced by the program (unless e.g.
--whole-archive is used).  This behavior breaks iostream with static
libstdc++.a (on systems that support init priorities) because we define
the global initializer for the standard stream objects in a separate TU
(ios_init.cc) from the stream object definitions (globals_io.cc).

This patch fixes this by moving the stream initialization object into
the same TU that defines the stream objects, so that any use of the
streams prevents the linker from discarding this global initializer.

	PR libstdc++/107701

libstdc++-v3/ChangeLog:

	* include/std/iostream (__ioinit): Adjust comment.
	* src/c++98/globals_io.cc: Include "io_base_init.h" here
	instead of ...
	* src/c++98/ios_init.cc: ... here.
	* src/c++98/ios_base_init.h (__ioinit): More comments.
	* testsuite/17_intro/static.cc: dg-do run instead of just link.

When trying to figure out what to do about alignment,
layout_compatible_type_p returns false if TYPE_ALIGN on
ENUMERAL_TYPE/CLASS_TYPE_P (but not scalar types?) differ, or if members
don't have the same positions.

What is in DR2583 doesn't say anything like that though, on the other side
it says that if the corresponding entities don't have the same alignment
requirements, they aren't part of the common initial sequence.

So, my understanding of this is we shouldn't check TYPE_ALIGN in
layout_compatible_type_p, but instead DECL_ALIGN in
next_common_initial_seqence.

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

	* typeck.cc (next_common_initial_sequence): Return false members have
	different DECL_ALIGN.
	(layout_compatible_type_p): Don't test TYPE_ALIGN of ENUMERAL_TYPE
	or CLASS_TYPE_P.

	* g++.dg/cpp2a/is-layout-compatible3.C: Expect enums with different
	alignas to be layout compatible, while classes with different
	alignas on members layout incompatible.
	* g++.dg/DRs/dr2583.C: New test.

As filed by Jonathan in the PR, I've screwed up the requires syntax
in the extended floating point specialization:
-    requires(__complex_type<_Tp>::type)
+    requires requires { typename __complex_type<_Tp>::type; }
and doing this change resulted in lots of errors because __complex_whatever
overfloads from extended floating point types were declared after the
templates which used them.

The following patch fixes that.

Bootstrapped/regtested on x86_64-linux and i686-linux, additionally
I've tested that with _GLIBCXX_HAVE_FLOAT128_MATH not being defined
while __STDCPP_FLOAT128_T__ defined one can still use
std::complex<std::float128_t> for basic arithmetic etc., just one can't
expect std::sin etc. to work in that case (because we don't have any
implementation).

2022-11-16  Jakub Jelinek  <jakub@redhat.com>
	    Jonathan Wakely  <jwakely@redhat.com>

	PR libstdc++/107649
	* include/std/complex (__complex_abs, __complex_arg, __complex_cos,
	__complex_cosh, __complex_exp, __complex_log, __complex_sin,
	__complex_sinh, __complex_sqrt, __complex_tan, __complex_tanh,
	__complex_pow): Move __complex__ _Float{16,32,64,128} and
	__complex__ decltype(0.0bf16) overloads earlier in the file.
	(complex): Fix up requires on the partial specialization for extended
	float types.
	(__complex_acos, __complex_asin, __complex_atan, __complex_acosh,
	__complex_asinh, __complex_atanh): Move
	__complex__ _Float{16,32,64,128} and __complex__ decltype(0.0bf16)
	overloads earlier in the file.

One thing that doesn't work properly is the same problem as I've filed
yesterday for static operator() - PR107624 - that side-effects of
the postfix-expression on which the call or subscript operator are
applied are thrown away, I assume we have to add them into COMPOUND_EXPR
somewhere after we find out that the we've chosen a static member function
operator.

On Mon, Nov 14, 2022 at 06:29:44PM -0500, Jason Merrill wrote:
> Indeed.  The code in build_new_method_call for this case has the comment
>
>               /* In an expression of the form `a->f()' where `f' turns
>                  out to be a static member function, `a' is
>                  none-the-less evaluated.  */

Had to tweak 3 spots for this.  Furthermore, found that if in non-pedantic
C++20 compilation static operator[] is accepted, we required that it has 2
arguments, I think it is better to require exactly one because that case
is the only one that will actually work in C++20 and older.

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

	PR c++/107624
	* call.cc (keep_unused_object_arg): New function.
	(build_op_call): Use it.
	(build_op_subscript): Likewise.
	(build_new_op): Similarly for ARRAY_REF.
	(build_new_method_call): Use it.
	* decl.cc (grok_op_properties): For C++20 and earlier, if operator[]
	is static member function, require exactly one parameter rather than
	exactly two parameters.

	* g++.dg/cpp23/static-operator-call4.C: New test.
	* g++.dg/cpp23/subscript10.C: New test.
	* g++.dg/cpp23/subscript11.C: New test.

gcc/ChangeLog:

	PR target/107676
	* doc/invoke.texi (-mrelax-cmpxchg-loop): Reword description.

All multiplication instructions are fully pipelined, except AVX256
instructions on Zen 1, which issue over two cycles on a 128-bit unit.
Correct the model accordingly to reduce combinatorial explosion in
automaton tables.

Top znver table sizes in insn-automata.o:

Before:

30056 r znver1_fp_min_issue_delay
120224 r znver1_fp_transitions

After:

6720 r znver1_fp_min_issue_delay
53760 r znver1_fp_transitions

gcc/ChangeLog:

	PR target/87832
	* config/i386/znver.md: (znver1_fp_op_mul): Correct cycles in
	the reservation.
	(znver1_fp_op_mul_load): Ditto.
	(znver1_mmx_mul): Ditto.
	(znver1_mmx_load): Ditto.
	(znver1_ssemul_ss_ps): Ditto.
	(znver1_ssemul_ss_ps_load): Ditto.
	(znver1_ssemul_avx256_ps): Ditto.
	(znver1_ssemul_avx256_ps_load): Ditto.
	(znver1_ssemul_sd_pd): Ditto.
	(znver1_ssemul_sd_pd_load): Ditto.
	(znver2_ssemul_sd_pd): Ditto.
	(znver2_ssemul_sd_pd_load): Ditto.
	(znver1_ssemul_avx256_pd): Ditto.
	(znver1_ssemul_avx256_pd_load): Ditto.
	(znver1_sseimul): Ditto.
	(znver1_sseimul_avx256): Ditto.
	(znver1_sseimul_load): Ditto.
	(znver1_sseimul_avx256_load): Ditto.
	(znver1_sseimul_di): Ditto.
	(znver1_sseimul_load_di): Ditto.

Correct modeling of division instructions in the SIMD/FP domain for
AMD Zen architectures and avoid combinatorial explosion of automaton
tables by modeling the separate floating-point division unit and
correcting reservations to reflect reciprocal throughput of the
corresponding instructions, similar to earlier commit
5cee5f94 ("i386: correct integer division modeling in znver.md").

Division is partially pipelined and some instructions have fractional
throughput (e.g. Zen 3 can issue divss and divsd each 3.5 and 4.5
cycles on average, respectively). Considering these CPUs implement
out-of-order execution, the model doesn't need to be exact to the last
cycle, so simplify it by using 4/5 cycles for SF/DF modes, and not
modeling the fact that FP3 pipe is occupied for one cycle.

Top znver table sizes in insn-automata.o:

Before:

428108 r znver1_fp_min_issue_delay
856216 r znver1_fp_transitions

After:

30056 r znver1_fp_min_issue_delay
120224 r znver1_fp_transitions

gcc/ChangeLog:

	PR target/87832
	* config/i386/znver.md (znver1_fdiv): New automaton.
	(znver1-fdiv): New unit.
	(znver1_fp_op_div): Correct unit and cycles in the reservation.
	(znver1_fp_op_div_load): Ditto.
	(znver1_fp_op_idiv_load): Ditto.
	(znver2_fp_op_idiv_load): Ditto.
	(znver1_ssediv_ss_ps): Ditto.
	(znver1_ssediv_ss_ps_load): Ditto.
	(znver1_ssediv_sd_pd): Ditto.
	(znver1_ssediv_sd_pd_load): Ditto.
	(znver1_ssediv_avx256_ps): Ditto.
	(znver1_ssediv_avx256_ps_load): Ditto.
	(znver1_ssediv_avx256_pd): Ditto.
	(znver1_ssediv_avx256_pd_load): Ditto.

The recent changes to FilteringTypePrinter affect the result of
gdb.lookup_type('std::string') in StdExpAnyPrinter, causing it to always
return the std::__cxx11::basic_string specialization. This then causes a
gdb.error exception when trying to lookup the std::any manager type for
a specliaization using that string, but that manager was never
instantiated in the program. This causes FAILs when running the tests
with -D_GLIBCXX_USE_CXX11_ABI=0:

FAIL: libstdc++-prettyprinters/libfundts.cc print as
FAIL: libstdc++-prettyprinters/libfundts.cc print as

The ugly solution used in this patch is to repeat the lookup for every
type that std::string could be a typedef for, and hope it only works for
one of them.

libstdc++-v3/ChangeLog:

	* python/libstdcxx/v6/printers.py (StdExpAnyPrinter): Make
	expansion of std::string in manager name more robust.

libstdc++-v3/ChangeLog:

	* python/libstdcxx/v6/printers.py (is_specialization_of): Fix
	incorrect terminology in docstring and describe arguments.
	(FilteringTypePrinter): Add default argument for new parameter,
	enhance docstring.

Add __builtin_gcn_kernarg_ptr to avoid using hard-coded register values
and permit future ABI changes while keeping the API.

gcc/ChangeLog:

	* config/gcn/gcn-builtins.def (KERNARG_PTR): Add.
	* config/gcn/gcn.cc (gcn_init_builtin_types): Change siptr_type_node,
	sfptr_type_node and voidptr_type_node from FLAT to ADDR_SPACE_DEFAULT.
	(gcn_expand_builtin_1): Handle GCN_BUILTIN_KERNARG_PTR.
	(gcn_oacc_dim_size): Return in ADDR_SPACE_FLAT.

libgomp/ChangeLog:

	* config/gcn/team.c (gomp_gcn_enter_kernel): Use
	__builtin_gcn_kernarg_ptr instead of asm ("s8").

Co-Authored-By: Andrew Stubbs <ams@codesourcery.com>

Replace lots of repeated checks against strings with a hash_map lookup.
Add some missing type-checking for handling known functions (e.g. checks
for pointer types).

gcc/analyzer/ChangeLog:
	* analyzer.h (known_function::matches_call_types_p): New vfunc.
	(known_function::impl_call_pre): Provide base implementation.
	(known_function::impl_call_post): New vfunc.
	(register_known_functions): New.
	* engine.cc (impl_run_checkers): Call register_known_functions.
	* region-model-impl-calls.cc (region_model::impl_call_accept):
	Convert to...
	(class known_function_accept): ...this.
	(region_model::impl_call_bind): Convert to...
	(class known_function_bind): ...this.
	(region_model::impl_call_connect): Convert to...
	(class known_function_connect): ...this.
	(region_model::impl_call_listen): Convert to...
	(class known_function_listen): ...this.
	(region_model::impl_call_socket): Convert to...
	(class known_function_socket): ...this.
	(register_known_functions): New.
	* region-model.cc (region_model::on_call_pre): Remove special
	case for "bind" in favor of the known_function-handling dispatch.
	Add call to known_function::matches_call_types_p to latter.
	(region_model::on_call_post): Remove special cases for "accept",
	"bind", "connect", "listen", and "socket" in favor of dispatch
	to known_function::impl_call_post.
	* region-model.h (region_model::impl_call_accept): Delete decl.
	(region_model::impl_call_bind): Delete decl.
	(region_model::impl_call_connect): Delete decl.
	(region_model::impl_call_listen): Delete decl.
	(region_model::impl_call_socket): Delete decl.
	* sm-fd.cc: Update comments.

gcc/testsuite/ChangeLog:
	* gcc.dg/plugin/analyzer_kernel_plugin.c
	(copy_across_boundary_fn::matches_call_types_p): New.
	* gcc.dg/plugin/analyzer_known_fns_plugin.c
	(known_function_returns_42::matches_call_types_p): New.
	(known_function_attempt_to_copy::matches_call_types_p): New.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

gcc/ChangeLog:
	* Makefile.in (ANALYZER_OBJS): Add analyzer/checker-event.o.

gcc/analyzer/ChangeLog:
	* checker-event.cc: New file, split out from...
	* checker-path.cc: ...this file.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

gcc/
	PR target/107645
	* config/m68k/predicates.md (symbolic_operand): Return false
	when UNSPEC is under the CONST node.

This patch fixes a wrong placed closing bracket in the RISC-V option
list and an unneeded @gol in the PRU option list in invoke.texi.

gcc/ChangeLog:

	* doc/invoke.texi: Fix PRU/RISC-V option list formatting.

The following patch implements CWG 2654.

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

	* typeck.cc (cp_build_modify_expr): Implement CWG 2654
	- Un-deprecation of compound volatile assignments.  Remove
	-Wvolatile warning about compound volatile assignments.

	* g++.dg/cpp2a/volatile1.C (fn2, fn3, racoon): Adjust expected
	diagnostics.
	* g++.dg/cpp2a/volatile3.C (fn2, fn3, racoon): Likewise.
	* g++.dg/cpp2a/volatile5.C (f): Likewise.
	* g++.dg/ext/vector25.C (foo): Don't expect a warning.
	* g++.dg/cpp1y/new1.C (test_unused): Likewise.

If lhd_set_decl_assembler_name is invoked - in particular if
!TREE_PUBLIC (decl) && !DECL_FILE_SCOPE_P (decl) - the '.nohost' suffix
might change to '.nohost.2'. This happens for the existing reverse offload
testcases via cgraph_node::analyze and is a side effect of
r13-3455-g178ac530fe67e4f2fc439cc4ce89bc19d571ca31 for some reason.

The solution is to not only check for a tailing '$nohost' but also for
'$nohost$' in nvptx/mkoffload.cc.

gcc/ChangeLog:

	* config/nvptx/mkoffload.cc (process): Recognize '$nohost$...'
	besides tailing '$nohost' as being for reverse offload.

The following patch adds parsing of attributes to concept definition,
allows deprecated attribute to be specified (as CONCEPT_DECL now needs
to be checked in c-family/c-attribs.cc, I had to move its declaration
from cp/*.def to c-family/*.def) and checks TREE_DEPRECATED in
build_standard_check (not sure if that is the right spot, or whether
it shouldn't be checked also for variable and function concepts and
how to write testcase coverage for that).

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

gcc/c-family/
	* c-common.def (CONCEPT_DECL): New tree, moved here from
	cp-tree.def.
	* c-common.cc (c_common_init_ts): Handle CONCEPT_DECL.
	* c-attribs.cc (handle_deprecated_attribute): Allow deprecated
	attribute on CONCEPT_DECL.
gcc/cp/
	* cp-tree.def (CONCEPT_DECL): Move to c-common.def.
	* cp-objcp-common.cc (cp_common_init_ts): Don't handle CONCEPT_DECL
	here.
	* cp-tree.h (finish_concept_definition): Add ATTRS parameter.
	* parser.cc (cp_parser_concept_definition): Parse attributes in
	between identifier and =.  Adjust finish_concept_definition
	caller.
	* pt.cc (finish_concept_definition): Add ATTRS parameter.  Call
	cplus_decl_attributes.
	* constraint.cc (build_standard_check): If CONCEPT_DECL is
	TREE_DEPRECATED, emit -Wdeprecated-declaration warnings.
gcc/testsuite/
	* g++.dg/cpp2a/concepts-dr2428.C: New test.

The following testcase ICEs, because when !HONOR_NANS but
HONOR_SIGNED_ZEROS, if we see
lhs = op1 * op2;
and know that lhs is [-0.0, 0.0] and op2 is [0.0, 0.0], the
division of these two yields UNDEFINED and clear_nan () on it
fails an assert.  With HONOR_NANS it would actually result in
a known NAN, but when NANs aren't honored, we clear the NAN bits.
Now, for the above case we actually don't know anything about
the op1 range (except that it isn't a NAN/INF because of
!HONOR_NANS !HONOR_INFINITIES), so I think the best is just
to return VARYING for the case we get UNDEFINED as well.

If we want, the op[12]_range methods perhaps can handle the
corner cases earlier separately, say for
lhs [0.0, 0.0] and op2 [0.0, 0.0] when HONOR_SIGNED_ZEROS this
would be just [0.0, MAX].

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

	PR tree-optimization/107668
	* range-op-float.cc (float_binary_op_range_finish): Set VARYING
	also when r is UNDEFINED.

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

Once we found a matching FilteringTypePrinter instance we look for the associated
typedef and check that the returned Python Type is equal to the Type to recognize.
But gdb Python Type includes properties to distinguish a typedef from the actual
type. So use gdb.types.get_basic_type to check if we are indeed on the same type.

Additionnaly enhance FilteringTypePrinter matching mecanism by introducing targ1 that,
if not None, will be used as the 1st template parameter.

libstdc++-v3/ChangeLog:

	* python/libstdcxx/v6/printers.py (FilteringTypePrinter): Rename 'match' field
	'template'. Add self.targ1 to specify the first template parameter of the instantiation
	to match.
	(add_one_type_printer): Add targ1 optional parameter, default to None.
	Use gdb.types.get_basic_type to compare the type to recognize and the type
	returned from the typedef lookup.
	(register_type_printers): Adapt calls to add_one_type_printers.

After prologue and epilogue generation, the judgement on whether
one memory access onto stack frame may trap or not could change,
since we get more exact stack information by now.

As PR90259 shows, some memory access becomes impossible to trap
any more after prologue and epilogue generation, it can make
subsequent optimization be able to remove it if safe, but it
results in unexpected control flow status due to REG_EH_REGION
note missing.

This patch proposes to try to remove EH edges with function
purge_all_dead_edges after prologue and epilogue generation,
it simplifies CFG as early as we can and don't need any fixup
in downstream passes.

CFG simplification result with PR90259's case as example:

*before*

   18: %1:TF=call [`__gcc_qdiv'] argc:0
      REG_EH_REGION 0x2
   77: NOTE_INSN_BASIC_BLOCK 3
   19: NOTE_INSN_DELETED
   20: NOTE_INSN_DELETED
  110: [%31:SI+0x20]=%1:DF
      REG_EH_REGION 0x2
  116: NOTE_INSN_BASIC_BLOCK 4
  111: [%31:SI+0x28]=%2:DF
      REG_EH_REGION 0x2
   22: NOTE_INSN_BASIC_BLOCK 5
  108: %0:DF=[%31:SI+0x20]
      REG_EH_REGION 0x2
  117: NOTE_INSN_BASIC_BLOCK 6
  109: %1:DF=[%31:SI+0x28]
      REG_EH_REGION 0x2
   79: NOTE_INSN_BASIC_BLOCK 7
   26: [%31:SI+0x18]=%0:DF
  104: pc=L69
  105: barrier

*after*

   18: %1:TF=call [`__gcc_qdiv'] argc:0
      REG_EH_REGION 0x2
   77: NOTE_INSN_BASIC_BLOCK 3
   19: NOTE_INSN_DELETED
   20: NOTE_INSN_DELETED
  110: [%31:SI+0x20]=%1:DF
  111: [%31:SI+0x28]=%2:DF
  108: %0:DF=[%31:SI+0x20]
  109: %1:DF=[%31:SI+0x28]
   26: [%31:SI+0x18]=%0:DF
  104: pc=L69
  105: barrier

	PR rtl-optimization/90259

gcc/ChangeLog:

	* function.cc (rest_of_handle_thread_prologue_and_epilogue): Add
	parameter fun, and call function purge_all_dead_edges.
	(pass_thread_prologue_and_epilogue::execute): Name unamed parameter
	as fun, and use it for rest_of_handle_thread_prologue_and_epilogue.

gcc/testsuite/ChangeLog:

	* g++.target/powerpc/pr90259.C: New.

It seems wrong to issue a -Wignored-qualifiers warning for code like:

  static_assert(!is_same_v<void(*)(), const void(*)()>);

because there the qualifier matters.  Likewise in template
specialization:

  template<typename T> struct S { };
  template<> struct S<void(*)()> { };
  template<> struct S<const void(*)()> { }; // OK, not a redefinition

And likewise in other type-id contexts such as trailing-return-type:

  auto g() -> const void (*)();

This patch limits the warning to the function declaration context only.

	PR c++/107492

gcc/cp/ChangeLog:

	* decl.cc (grokdeclarator): Only emit a -Wignored-qualifiers warning
	when funcdecl_p.

gcc/testsuite/ChangeLog:

	* g++.dg/warn/Wignored-qualifiers3.C: New test.

The Zihintpause extension uses an opcode from the 'fence' opcode range
to add a true hint instruction (i.e. if it is not supported on any
given platform, the 'fence' that is encoded will not enforce any
specific ordering on memory accesses) for entering a low-power state
(e.g. in an idle thread).  We expose this new instruction through a
machine-dependent builtin to allow generating it without a requirement
for any inline assembly.

Given that the encoding of 'pause' is valid (as a 'fence' encoding)
even for processors that do not (yet) support Zihintpause, we make
this builtin available without any further TARGET_* constraints.

gcc/ChangeLog:

	* config/riscv/riscv-builtins.cc (struct riscv_builtin_description):
	add the pause machine-dependent builtin with no result and no
	arguments; mark it as always present (pause is a true hint
	that encodes into a fence-insn, if not supported with the new
	pause semantics).
	* config/riscv/riscv-ftypes.def: Add type for void -> void.
	* config/riscv/riscv.md (riscv_pause): Add risc_pause and
	UNSPECV_PAUSE
	* doc/extend.texi: Document __builtin_riscv_pause.
	* optabs.cc (maybe_gen_insn): Allow nops == 0 (void -> void).

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/builtin_pause.c: New test.

Fix a maybe-uninitialized warning introduced in commit:
068baae1 bpf: add preserve_field_info builtin

gcc/

	* config/bpf/bpf.cc (bpf_expand_builtin): Avoid use of uninitialized
	variable in error case.