* sr.po, sv.po: Update.

gcc/po/
	* be.po, da.po, de.po, el.po, es.po, fi.po, fr.po, hr.po, id.po,
	ja.po, nl.po, ru.po, sr.po, sv.po, tr.po, uk.po, vi.po, zh_CN.po,
	zh_TW.po: Update.

libcpp/po/
	* be.po, ca.po, da.po, de.po, el.po, eo.po, es.po, fi.po, fr.po,
	id.po, ja.po, ka.po, nl.po, pt_BR.po, ro.po, ru.po, sr.po, sv.po,
	tr.po, uk.po, vi.po, zh_CN.po, zh_TW.po: Update.

gcc/po/
	* gcc.pot: Regenerate.

libcpp/po/
	* cpplib.pot: Regenerate.

	* ka.po: New.

	* eo.po: Update.

2022 -> 2023

C2x supports __VA_OPT__, so adjust libcpp not to pedwarn for uses of
it (or of not passing any variable arguments to a variable-arguments
macro) in standard C2x mode.

I didn't try to duplicate existing tests for the details of the
feature, just verified -pedantic-errors handling is as expected.  And
there's a reasonable argument (bug 98859) that __VA_OPT__ shouldn't be
diagnosed in older standard modes at all (as opposed to not passing
any variable arguments to a variable-arguments macro, for which older
versions of the C standard require a diagnostic as a constraint
violation); that argument applies to C as much as to C++, but I
haven't made any changes in that regard.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

libcpp/
	* init.cc (lang_defaults): Enable va_opt for STDC2X.
	* lex.cc (maybe_va_opt_error): Adjust diagnostic message for C.
	* macro.cc (_cpp_arguments_ok): Update comment.

gcc/testsuite/
	* gcc.dg/cpp/c11-vararg-1.c, gcc.dg/cpp/c2x-va-opt-1.c: New tests.

This reverts commit 251c72a6.

This patch implements the --enable-host-pie configure option which
makes the compiler executables PIE.  This can be used to enhance
protection against ROP attacks, and can be viewed as part of a wider
trend to harden binaries.

It is similar to the option --enable-host-shared, except that --e-h-s
won't add -shared to the linker flags whereas --e-h-p will add -pie.
It is different from --enable-default-pie because that option just
adds an implicit -fPIE/-pie when the compiler is invoked, but the
compiler itself isn't PIE.

Since r12-5768-gfe7c3ecf, PCH works well with PIE, so there are no PCH
regressions.

When building the compiler, the build process may use various in-tree
libraries; these need to be built with -fPIE so that it's possible to
use them when building a PIE.  For instance, when --with-included-gettext
is in effect, intl object files must be compiled with -fPIE.  Similarly,
when building in-tree gmp, isl, mpfr and mpc, they must be compiled with
-fPIE.

I plan to add an option to link with -Wl,-z,now.

ChangeLog:

	* Makefile.def: Pass $(PICFLAG) to AM_CFLAGS for gmp, mpfr, mpc, and
	isl.
	* Makefile.in: Regenerate.
	* Makefile.tpl: Set PICFLAG.
	* configure.ac (--enable-host-pie): New check.  Set PICFLAG after this
	check.
	* configure: Regenerate.

c++tools/ChangeLog:

	* Makefile.in: Rename PIEFLAG to PICFLAG.  Set LD_PICFLAG.  Use it.
	Use pic/libiberty.a if PICFLAG is set.
	* configure.ac (--enable-default-pie): Set PICFLAG instead of PIEFLAG.
	(--enable-host-pie): New check.
	* configure: Regenerate.

fixincludes/ChangeLog:

	* Makefile.in: Set and use PICFLAG and LD_PICFLAG.  Use the "pic"
	build of libiberty if PICFLAG is set.
	* configure.ac:
	* configure: Regenerate.

gcc/ChangeLog:

	* Makefile.in: Set LD_PICFLAG.  Use it.  Set enable_host_pie.
	Remove NO_PIE_CFLAGS and NO_PIE_FLAG.  Pass LD_PICFLAG to
	ALL_LINKERFLAGS.  Use the "pic" build of libiberty if --enable-host-pie.
	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG and LD_PICFLAG after this
	check.
	* configure: Regenerate.
	* doc/install.texi: Document --enable-host-pie.

gcc/d/ChangeLog:

	* Make-lang.in: Remove NO_PIE_CFLAGS.

intl/ChangeLog:

	* Makefile.in: Use @PICFLAG@ in COMPILE as well.
	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG after this check.
	* configure: Regenerate.

libcody/ChangeLog:

	* Makefile.in: Pass LD_PICFLAG to LDFLAGS.
	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG and LD_PICFLAG after this
	check.
	* configure: Regenerate.

libcpp/ChangeLog:

	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG after this check.
	* configure: Regenerate.

libdecnumber/ChangeLog:

	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG after this check.
	* configure: Regenerate.

libiberty/ChangeLog:

	* configure.ac: Also set shared when enable_host_pie.
	* configure: Regenerate.

zlib/ChangeLog:

	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG after this check.
	* configure: Regenerate.

In directives.cc, do_pragma() contains logic to handle a case such as the new
testcase pragma-omp-unknown.c, where an unknown pragma was the result of macro
expansion (for pragma namespaces that permit expansion). This no longer works
correctly as shown by the testcase, fixed by adding PREV_WHITE to the flags on
the second token to prevent an unwanted paste.  Also fixed the memory leak,
since the temporary tokens are pushed on their own context, nothing prevents
freeing of the buffer that holds them when the context is eventually popped.

libcpp/ChangeLog:

	* directives.cc (do_pragma): Fix memory leak in token buffer.  Fix
	unwanted paste between two tokens.

gcc/testsuite/ChangeLog:

	* c-c++-common/gomp/pragma-omp-unknown.c: New test.

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>

libcpp/ChangeLog:

	* config.in: Re-configure.

libstdc++-v3/ChangeLog:

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

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.

Code such as:

 #include __FILE__

can interact poorly with the *-prefix-map options when cross compiling. In
general you're after to remap filenames for use in target context but the
local paths should be used to find include files at compile time. Ingoring
filename remapping for directives allows avoiding such failures.

Fix this to improve such usage and then document this against file-prefix-map
(referenced by the other *-prefix-map options) to make the behaviour clear
and defined.

libcpp/ChangeLog:

	* macro.cc (_cpp_builtin_macro_text): Don't remap filenames within
	directives.

gcc/ChangeLog:

	* doc/invoke.texi: Document prefix-maps don't affect directives.

It's not currently possible to use a C++11 raw string containing a newline as
part of the definition of a macro, or in any other preprocessing directive,
such as:

 #define X R"(two
lines)"

 #error R"(this error has
two lines)"

Add support for that by relaxing the conditions under which
_cpp_get_fresh_line() refuses to get a new line. For the case of lexing a raw
string, it's OK to do so as long as there is another line within the current
buffer. The code in cpp_get_fresh_line() was refactored into a new function
get_fresh_line_impl(), so that the new logic is applied only when processing a
raw string and not any other times.

libcpp/ChangeLog:

	PR preprocessor/55971
	* lex.cc (get_fresh_line_impl): New function refactoring the code
	from...
	(_cpp_get_fresh_line): ...here.
	(lex_raw_string): Use the new version of get_fresh_line_impl() to
	support raw strings containing new lines when processing a directive.

gcc/testsuite/ChangeLog:

	PR preprocessor/55971
	* c-c++-common/raw-string-directive-1.c: New test.
	* c-c++-common/raw-string-directive-2.c: New test.

gcc/c-family/ChangeLog:

	PR preprocessor/55971
	* c-ppoutput.cc (adjust_for_newlines): Update comment.

The following pseudo-patch regenerates the libcpp tables with Unicode 15.0.0
which added 4489 new characters.

As mentioned previously, this isn't just a matter of running the
two libcpp/make*.cc programs on the new Unicode files, but one needs
to manually update a table inside of makeuname2c.cc according to
a table in Unicode text (which is partially reflected in the text
files, but e.g. in Unicode 14.0.0 not 100% accurately, in 15.0.0
actually accurately).
I've also added some randomly chosen subset of those 4489 new
characters to a testcase.

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

gcc/testsuite/
	* c-c++-common/cpp/named-universal-char-escape-1.c: Add tests for some
	characters newly added in Unicode 15.0.0.
libcpp/
	* makeuname2c.cc (struct generated): Update from Unicode 15.0.0
	table 4-8.
	* ucnid.h: Regenerated for Unicode 15.0.0.
	* uname2c.h: Likewise.

When a GTY'ed struct is streamed to PCH, any plain char* pointers it contains
(whether they live in GC-controlled memory or not) will be marked for PCH
output by the routine gt_pch_note_object in ggc-common.cc. This routine
special-cases plain char* strings, and in particular it uses strlen() to get
their length. Thus it does not handle strings with embedded null bytes, but it
is possible for something PCH cares about (such as a string literal token in a
macro definition) to contain such embedded nulls. To fix that up, add a new
GTY option "string_length" so that gt_pch_note_object can be informed the
actual length it ought to use, and use it in the relevant libcpp structs
(cpp_string and ht_identifier) accordingly.

gcc/ChangeLog:

	* gengtype.cc (output_escaped_param): Add missing const.
	(get_string_option): Add missing check for option type.
	(walk_type): Support new "string_length" GTY option.
	(write_types_process_field): Likewise.
	* ggc-common.cc (gt_pch_note_object): Add optional length argument.
	* ggc.h (gt_pch_note_object): Adjust prototype for new argument.
	(gt_pch_n_S2): Declare...
	* stringpool.cc (gt_pch_n_S2): ...new function.
	* doc/gty.texi: Document new GTY((string_length)) option.

libcpp/ChangeLog:

	* include/cpplib.h (struct cpp_string): Use new "string_length" GTY.
	* include/symtab.h (struct ht_identifier): Likewise.

gcc/testsuite/ChangeLog:

	* g++.dg/pch/pch-string-nulls.C: New test.
	* g++.dg/pch/pch-string-nulls.Hs: New test.

C2x has, like C++, adopted rules for identifiers based directly on an
unversioned normative reference to Unicode.  Make libcpp follow those
rules for c2x / gnu2x standards (this involves bringing back a flag
separate from the C++ one for whether to use these identifier rules,
but this time enabled for all C++ language versions since that was the
conclusion adopted for C++ identifier handling).

There is one change here that affects C++.  I believe the new
normative requirement for NFC only applies to identifiers, not to the
use of identifier-continue characters in pp-numbers, where there is no
such requirement and so the diagnostic ought to be a warning not a
pedwarn in pp-numbers, and that this is the case for both C and C++.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

libcpp/
	* charset.cc (ucn_valid_in_identifier): Check xid_identifiers not
	cplusplus to determine whether to use CXX23 and NXX23 flags.
	* include/cpplib.h (struct cpp_options): Add xid_identifiers.
	* init.cc (struct lang_flags, lang_defaults): Add xid_identifiers.
	(cpp_set_lang): Set xid_identifiers.
	* lex.cc (warn_about_normalization): Add parameter identifier.
	Only pedwarn about non-NFC for identifiers, not pp-numbers.
	(_cpp_lex_direct): Update calls to warn_about_normalization.

gcc/testsuite/
	* gcc.dg/cpp/c2x-ucnid-1-utf8.c, gcc.dg/cpp/c2x-ucnid-1.c: New
	tests.

Here is a complete patch to add std::bfloat16_t support on
x86 (AArch64 and ARM left for later).  Almost no BFmode optabs
are added by the patch, so for binops/unops it extends to SFmode
first and then truncates back to BFmode.
For {HF,SF,DF,XF,TF}mode -> BFmode conversions libgcc has implementations
of all those conversions so that we avoid double rounding, for
BFmode -> {DF,XF,TF}mode conversions to avoid growing libgcc too much
it emits BFmode -> SFmode conversion first and then converts to the even
wider mode, neither step should be imprecise.
For BFmode -> HFmode, it first emits a precise BFmode -> SFmode conversion
and then SFmode -> HFmode, because neither format is subset or superset
of the other, while SFmode is superset of both.
expr.cc then contains a -ffast-math optimization of the BF -> SF and
SF -> BF conversions if we don't optimize for space (and for the latter
if -frounding-math isn't enabled either).
For x86, perhaps truncsfbf2 optab could be defined for TARGET_AVX512BF16
but IMNSHO should FAIL if !flag_finite_math || flag_rounding_math
|| !flag_unsafe_math_optimizations, because I think the insn doesn't
raise on sNaNs, hardcodes round to nearest and flushes denormals to zero.
By default (unless x86 -fexcess-precision=16) we use float excess
precision for BFmode, so truncate only on explicit casts and assignments.
The patch introduces a single __bf16 builtin - __builtin_nansf16b,
because (__bf16) __builtin_nansf ("") will drop the sNaN into qNaN,
and uses f16b suffix instead of bf16 because there would be ambiguity on
log vs. logb - __builtin_logbf16 could be either log with bf16 suffix
or logb with f16 suffix.  In other cases libstdc++ should mostly use
__builtin_*f for std::bfloat16_t overloads (we have a problem with
std::nextafter though but that one we have also for std::float16_t).

2022-10-14  Jakub Jelinek  <jakub@redhat.com>

gcc/
	* tree-core.h (enum tree_index): Add TI_BFLOAT16_TYPE.
	* tree.h (bfloat16_type_node): Define.
	* tree.cc (excess_precision_type): Promote bfloat16_type_mode
	like float16_type_mode.
	(build_common_tree_nodes): Initialize bfloat16_type_node if
	BFmode is supported.
	* expmed.h (maybe_expand_shift): Declare.
	* expmed.cc (maybe_expand_shift): No longer static.
	* expr.cc (convert_mode_scalar): Don't ICE on BF -> HF or HF -> BF
	conversions.  If there is no optab, handle BF -> {DF,XF,TF,HF}
	conversions as separate BF -> SF -> {DF,XF,TF,HF} conversions, add
	-ffast-math generic implementation for BF -> SF and SF -> BF
	conversions.
	* builtin-types.def (BT_BFLOAT16, BT_FN_BFLOAT16_CONST_STRING): New.
	* builtins.def (BUILT_IN_NANSF16B): New builtin.
	* fold-const-call.cc (fold_const_call): Handle CFN_BUILT_IN_NANSF16B.
	* config/i386/i386.cc (classify_argument): Handle E_BCmode.
	(ix86_libgcc_floating_mode_supported_p): Also return true for BFmode
	for -msse2.
	(ix86_mangle_type): Mangle BFmode as DF16b.
	(ix86_invalid_conversion, ix86_invalid_unary_op,
	ix86_invalid_binary_op): Remove.
	(TARGET_INVALID_CONVERSION, TARGET_INVALID_UNARY_OP,
	TARGET_INVALID_BINARY_OP): Don't redefine.
	* config/i386/i386-builtins.cc (ix86_bf16_type_node): Remove.
	(ix86_register_bf16_builtin_type): Use bfloat16_type_node rather than
	ix86_bf16_type_node, only create it if still NULL.
	* config/i386/i386-builtin-types.def (BFLOAT16): Likewise.
	* config/i386/i386.md (cbranchbf4, cstorebf4): New expanders.
gcc/c-family/
	* c-cppbuiltin.cc (c_cpp_builtins): If bfloat16_type_node,
	predefine __BFLT16_*__ macros and for C++23 also
	__STDCPP_BFLOAT16_T__.  Predefine bfloat16_type_node related
	macros for -fbuilding-libgcc.
	* c-lex.cc (interpret_float): Handle CPP_N_BFLOAT16.
gcc/c/
	* c-typeck.cc (convert_arguments): Don't promote __bf16 to
	double.
gcc/cp/
	* cp-tree.h (extended_float_type_p): Return true for
	bfloat16_type_node.
	* typeck.cc (cp_compare_floating_point_conversion_ranks): Set
	extended{1,2} if mv{1,2} is bfloat16_type_node.  Adjust comment.
gcc/testsuite/
	* lib/target-supports.exp (check_effective_target_bfloat16,
	check_effective_target_bfloat16_runtime, add_options_for_bfloat16):
	New.
	* gcc.dg/torture/bfloat16-basic.c: New test.
	* gcc.dg/torture/bfloat16-builtin.c: New test.
	* gcc.dg/torture/bfloat16-builtin-issignaling-1.c: New test.
	* gcc.dg/torture/bfloat16-complex.c: New test.
	* gcc.dg/torture/builtin-issignaling-1.c: Allow to be includable
	from bfloat16-builtin-issignaling-1.c.
	* gcc.dg/torture/floatn-basic.h: Allow to be includable from
	bfloat16-basic.c.
	* gcc.target/i386/vect-bfloat16-typecheck_2.c: Adjust expected
	diagnostics.
	* gcc.target/i386/sse2-bfloat16-scalar-typecheck.c: Likewise.
	* gcc.target/i386/vect-bfloat16-typecheck_1.c: Likewise.
	* g++.target/i386/bfloat_cpp_typecheck.C: Likewise.
libcpp/
	* include/cpplib.h (CPP_N_BFLOAT16): Define.
	* expr.cc (interpret_float_suffix): Handle bf16 and BF16 suffixes for
	C++.
libgcc/
	* config/i386/t-softfp (softfp_extensions): Add bfsf.
	(softfp_truncations): Add tfbf xfbf dfbf sfbf hfbf.
	(CFLAGS-extendbfsf2.c, CFLAGS-truncsfbf2.c, CFLAGS-truncdfbf2.c,
	CFLAGS-truncxfbf2.c, CFLAGS-trunctfbf2.c, CFLAGS-trunchfbf2.c): Add
	-msse2.
	* config/i386/libgcc-glibc.ver (GCC_13.0.0): Export
	__extendbfsf2 and __trunc{s,d,x,t,h}fbf2.
	* config/i386/sfp-machine.h (_FP_NANSIGN_B): Define.
	* config/i386/64/sfp-machine.h (_FP_NANFRAC_B): Define.
	* config/i386/32/sfp-machine.h (_FP_NANFRAC_B): Define.
	* soft-fp/brain.h: New file.
	* soft-fp/truncsfbf2.c: New file.
	* soft-fp/truncdfbf2.c: New file.
	* soft-fp/truncxfbf2.c: New file.
	* soft-fp/trunctfbf2.c: New file.
	* soft-fp/trunchfbf2.c: New file.
	* soft-fp/truncbfhf2.c: New file.
	* soft-fp/extendbfsf2.c: New file.
libiberty/
	* cp-demangle.h (D_BUILTIN_TYPE_COUNT): Increment.
	* cp-demangle.c (cplus_demangle_builtin_types): Add std::bfloat16_t
	entry.
	(cplus_demangle_type): Demangle DF16b.
	* testsuite/demangle-expected (_Z3xxxDF16b): New test.

	* ro.po: New.

This is the first in a series of patches to enable discriminator support
in AutoFDO.

This patch switches to tracking discriminators per statement/instruction
instead of per basic block. Tracking per basic block was problematic since
not all statements in a basic block needed a discriminator and, also, later
optimizations could move statements between basic blocks making correlation
during AutoFDO compilation unreliable. Tracking per statement also allows
us to assign different discriminators to multiple function calls in the same
basic block. A subsequent patch will add that support.

The idea of this patch is based on commit 4c311d95cf6d9519c3c20f641cc77af7df491fdf
by Dehao Chen in vendors/google/heads/gcc-4_8 but uses a slightly different
approach. In Dehao's work special (normally unused) location ids and side tables
were used to keep track of locations with discriminators. Things have changed
since then and I don't think we have unused location ids anymore. Instead,
I made discriminators a part of ad-hoc locations.

The difference from Dehao's work also includes support for discriminator
reading/writing in lto streaming and in modules.

Tested on x86_64-pc-linux-gnu.

gcc/ChangeLog:

	* basic-block.h: Remove discriminator from basic blocks.
	* cfghooks.cc (split_block_1): Remove discriminator from basic blocks.
	* final.cc (final_start_function_1): Switch from per-bb to per statement
	discriminator.
	(final_scan_insn_1): Don't keep track of basic block discriminators.
	(compute_discriminator): Switch from basic block discriminators to
	instruction discriminators.
	(insn_discriminator): New function to return instruction discriminator.
	(notice_source_line): Use insn_discriminator.
	* gimple-pretty-print.cc (dump_gimple_bb_header): Remove dumping of
	basic block discriminators.
	* gimple-streamer-in.cc (input_bb): Remove reading of basic block
	discriminators.
	* gimple-streamer-out.cc (output_bb): Remove writing of basic block
	discriminators.
	* input.cc (make_location): Pass 0 discriminator to COMBINE_LOCATION_DATA.
	(location_with_discriminator): New function to combine locus with
	a discriminator.
	(has_discriminator): New function to check if a location has a discriminator.
	(get_discriminator_from_loc): New function to get the discriminator
	from a location.
	* input.h: Declarations of new functions.
	* lto-streamer-in.cc (cmp_loc): Use discriminators in location comparison.
	(apply_location_cache): Keep track of current discriminator.
	(input_location_and_block): Read discriminator from stream.
	* lto-streamer-out.cc (clear_line_info): Set current discriminator to
	UINT_MAX.
	(lto_output_location_1): Write discriminator to stream.
	* lto-streamer.h: Add discriminator to cached_location.
	Add current_discr to lto_location_cache.
	Add current_discr to output_block.
	* print-rtl.cc (print_rtx_operand_code_i): Print discriminator.
	* rtl.h: Add extern declaration of insn_discriminator.
	* tree-cfg.cc (assign_discriminator): New function to assign a unique
	discriminator value to all statements in a basic block that have the given
	line number.
	(assign_discriminators): Assign discriminators to statement locations.
	* tree-pretty-print.cc (dump_location): Dump discriminators.
	* tree.cc (set_block): Preserve discriminator when setting block.
	(set_source_range): Preserve discriminator when setting source range.

gcc/cp/ChangeLog:
	* module.cc (write_location): Write discriminator.
	(read_location): Read discriminator.

libcpp/ChangeLog:

	* include/line-map.h: Add discriminator to location_adhoc_data.
	(get_combined_adhoc_loc): Add discriminator parameter.
	(get_discriminator_from_adhoc_loc): Add external declaration.
	(get_discriminator_from_loc): Add external declaration.
	(COMBINE_LOCATION_DATA): Add discriminator parameter.
	* lex.cc (get_location_for_byte_range_in_cur_line) Pass 0 discriminator
	in a call to COMBINE_LOCATION_DATA.
	(warn_about_normalization): Pass 0 discriminator in a call to
	COMBINE_LOCATION_DATA.
	(_cpp_lex_direct): Pass 0 discriminator in a call to
	COMBINE_LOCATION_DATA.
	* line-map.cc (location_adhoc_data_hash): Use discriminator compute
	location_adhoc_data hash.
	(location_adhoc_data_eq): Use discriminator when comparing
	location_adhoc_data.
	(can_be_stored_compactly_p): Check discriminator to determine
	compact storage.
	(get_combined_adhoc_loc): Add discriminator parameter.
	(get_discriminator_from_adhoc_loc): New function to get the discriminator
	from an ad-hoc location.
	(get_discriminator_from_loc): New function to get the discriminator
	from a location.

gcc/testsuite/ChangeLog:

	* c-c++-common/ubsan/pr85213.c: Pass -gno-statement-frontiers.

c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

The following patch implements the compiler part of C++23
P1467R9 - Extended floating-point types and standard names compiler part
by introducing _Float{16,32,64,128} as keywords and builtin types
like they are implemented for C already since GCC 7, with DF{16,32,64,128}_
mangling.
It also introduces _Float{32,64,128}x for C++ with the
https://github.com/itanium-cxx-abi/cxx-abi/pull/147
proposed mangling of DF{32,64,128}x.
The patch doesn't add anything for bfloat16_t support, as right now
__bf16 type refuses all conversions and arithmetic operations.
The patch wants to keep backwards compatibility with how __float128 has
been handled in C++ before, both for mangling and behavior in binary
operations, overload resolution etc.  So, there are some backend changes
where for C __float128 and _Float128 are the same type (float128_type_node
and float128t_type_node are the same pointer), but for C++ they are distinct
types which mangle differently and _Float128 is treated as extended
floating-point type while __float128 is treated as non-standard floating
point type.  The various C++23 changes about how floating-point types
are changed are actually implemented as written in the spec only if at least
one of the types involved is _Float{16,32,64,128,32x,64x,128x} (_FloatNx are
also treated as extended floating-point types) and kept previous behavior
otherwise.  For float/double/long double the rules are actually written that
they behave the same as before.
There is some backwards incompatibility at least on x86 regarding _Float16,
because that type was already used by that name and with the DF16_ mangling
(but only since GCC 12 and I think it isn't that widely used in the wild
yet).  E.g. config/i386/avx512fp16intrin.h shows the issues, where
in C or in GCC 12 in C++ one could pass 0.0f to a builtin taking _Float16
argument, but with the changes that is not possible anymore, one needs
to either use 0.0f16 or (_Float16) 0.0f.
We have also a problem with glibc headers, where since glibc 2.27
math.h and complex.h aren't compilable with these changes.  One gets
errors like:
In file included from /usr/include/math.h:43,
                 from abc.c:1:
/usr/include/bits/floatn.h:86:9: error: multiple types in one declaration
   86 | typedef __float128 _Float128;
      |         ^~~~~~~~~~
/usr/include/bits/floatn.h:86:20: error: declaration does not declare anything [-fpermissive]
   86 | typedef __float128 _Float128;
      |                    ^~~~~~~~~
In file included from /usr/include/bits/floatn.h:119:
/usr/include/bits/floatn-common.h:214:9: error: multiple types in one declaration
  214 | typedef float _Float32;
      |         ^~~~~
/usr/include/bits/floatn-common.h:214:15: error: declaration does not declare anything [-fpermissive]
  214 | typedef float _Float32;
      |               ^~~~~~~~
/usr/include/bits/floatn-common.h:251:9: error: multiple types in one declaration
  251 | typedef double _Float64;
      |         ^~~~~~
/usr/include/bits/floatn-common.h:251:16: error: declaration does not declare anything [-fpermissive]
  251 | typedef double _Float64;
      |                ^~~~~~~~
This is from snippets like:
 /* The remaining of this file provides support for older compilers.  */
 # if __HAVE_FLOAT128

 /* The type _Float128 exists only since GCC 7.0.  */
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
 typedef __float128 _Float128;
 #  endif
where it hardcodes that C++ doesn't have _Float{16,32,64,128,32x,64x,128x} support nor
{f,F}{16,32,64,128}{,x} literal suffixes nor _Complex _Float{16,32,64,128,32x,64x,128x}.
The patch fixincludes this for now and hopefully if this is committed, then
glibc can change those.  The patch changes those
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
conditions to
 #  if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
Another thing is mangling, as said above, Itanium C++ ABI specifies
DF <number> _ as _Float{16,32,64,128} mangling, but GCC was implementing
a mangling incompatible with that starting with DF for fixed point types.
Fixed point was never supported in C++ though, I believe the reason why
the mangling has been added was that due to a bug it would leak into the
C++ FE through decltype (0.0r) etc.  But that has been shortly after the
mangling was added fixed (I think in the same GCC release cycle), so we
now reject 0.0r etc. in C++.  If we ever need the fixed point mangling,
I think it can be readded but better with a different prefix so that it
doesn't conflict with the published standard manglings.  So, this patch
also kills the fixed point mangling and implements the DF <number> _
demangling.
The patch predefines __STDCPP_FLOAT{16,32,64,128}_T__ macros when
those types are available, but only for C++23, while the underlying types
are available in C++98 and later including the {f,F}{16,32,64,128} literal
suffixes (but those with a pedwarn for C++20 and earlier).  My understanding
is that it needs to be predefined by the compiler, on the other side
predefining even for older modes when <stdfloat> is a new C++23 header
would be weird.  One can find out if _Float{16,32,64,128,32x,64x,128x} is
supported in C++ by
__GNUC__ >= 13 && defined(__FLT{16,32,64,128,32X,64X,128X}_MANT_DIG__)
(but that doesn't work well with older G++ 13 snapshots).

As for std::bfloat16_t, three targets (aarch64, arm and x86) apparently
"support" __bf16 type which has the bfloat16 format, but isn't really
usable, e.g. {aarch64,arm,ix86}_invalid_conversion disallow any conversions
from or to type with BFmode, {aarch64,arm,ix86}_invalid_unary_op disallows
any unary operations on those except for ADDR_EXPR and
{aarch64,arm,ix86}_invalid_binary_op disallows any binary operation on
those.  So, I think we satisfy:
"If the implementation supports an extended floating-point type with the
properties, as specified by ISO/IEC/IEEE 60559, of radix (b) of 2, storage
width in bits (k) of 16, precision in bits (p) of 8, maximum exponent (emax)
of 127, and exponent field width in bits (w) of 8, then the typedef-name
std::bfloat16_t is defined in the header <stdfloat> and names such a type,
the macro __STDCPP_BFLOAT16_T__ is defined, and the floating-point literal
suffixes bf16 and BF16 are supported."
because we don't really support those right now.

2022-09-27  Jakub Jelinek  <jakub@redhat.com>

	PR c++/106652
	PR c++/85518
gcc/
	* tree-core.h (enum tree_index): Add TI_FLOAT128T_TYPE
	enumerator.
	* tree.h (float128t_type_node): Define.
	* tree.cc (build_common_tree_nodes): Initialize float128t_type_node.
	* builtins.def (DEF_FLOATN_BUILTIN): Adjust comment now that
	_Float<N> is supported in C++ too.
	* config/i386/i386.cc (ix86_mangle_type): Only mangle as "g"
	float128t_type_node.
	* config/i386/i386-builtins.cc (ix86_init_builtin_types): Use
	float128t_type_node for __float128 instead of float128_type_node
	and create it if NULL.
	* config/i386/avx512fp16intrin.h (_mm_setzero_ph, _mm256_setzero_ph,
	_mm512_setzero_ph, _mm_set_sh, _mm_load_sh): Use 0.0f16 instead of
	0.0f.
	* config/ia64/ia64.cc (ia64_init_builtins): Use
	float128t_type_node for __float128 instead of float128_type_node
	and create it if NULL.
	* config/rs6000/rs6000-c.cc (is_float128_p): Also return true
	for float128t_type_node if non-NULL.
	* config/rs6000/rs6000.cc (rs6000_mangle_type): Don't mangle
	float128_type_node as "u9__ieee128".
	* config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Use
	float128t_type_node for __float128 instead of float128_type_node
	and create it if NULL.
gcc/c-family/
	* c-common.cc (c_common_reswords): Change _Float{16,32,64,128} and
	_Float{32,64,128}x flags from D_CONLY to 0.
	(shorten_binary_op): Punt if common_type returns error_mark_node.
	(shorten_compare): Likewise.
	(c_common_nodes_and_builtins): For C++ record _Float{16,32,64,128}
	and _Float{32,64,128}x builtin types if available.  For C++
	clear float128t_type_node.
	* c-cppbuiltin.cc (c_cpp_builtins): Predefine
	__STDCPP_FLOAT{16,32,64,128}_T__ for C++23 if supported.
	* c-lex.cc (interpret_float): For q/Q suffixes prefer
	float128t_type_node over float128_type_node.  Allow
	{f,F}{16,32,64,128} suffixes for C++ if supported with pedwarn
	for C++20 and older.  Allow {f,F}{32,64,128}x suffixes for C++
	with pedwarn.  Don't call excess_precision_type for C++.
gcc/cp/
	* cp-tree.h (cp_compare_floating_point_conversion_ranks): Implement
	P1467R9 - Extended floating-point types and standard names except
	for std::bfloat16_t for now.  Declare.
	(extended_float_type_p): New inline function.
	* mangle.cc (write_builtin_type): Mangle float{16,32,64,128}_type_node
	as DF{16,32,64,128}_.  Mangle float{32,64,128}x_type_node as
	DF{32,64,128}x.  Remove FIXED_POINT_TYPE mangling that conflicts
	with that.
	* typeck2.cc (check_narrowing): If one of ftype or type is extended
	floating-point type, compare floating-point conversion ranks.
	* parser.cc (cp_keyword_starts_decl_specifier_p): Handle
	CASE_RID_FLOATN_NX.
	(cp_parser_simple_type_specifier): Likewise and diagnose missing
	_Float<N> or _Float<N>x support if not supported by target.
	* typeck.cc (cp_compare_floating_point_conversion_ranks): New function.
	(cp_common_type): If both types are REAL_TYPE and one or both are
	extended floating-point types, select common type based on comparison
	of floating-point conversion ranks and subranks.
	(cp_build_binary_op): Diagnose operation with floating point arguments
	with unordered conversion ranks.
	* call.cc (standard_conversion): For floating-point conversion, if
	either from or to are extended floating-point types, set conv->bad_p
	for implicit conversion from larger to smaller conversion rank or
	with unordered conversion ranks.
	(convert_like_internal): Emit a pedwarn on such conversions.
	(build_conditional_expr): Diagnose operation with floating point
	arguments with unordered conversion ranks.
	(convert_arg_to_ellipsis): Don't promote extended floating-point types
	narrower than double to double.
	(compare_ics): Implement P1467R9 [over.ics.rank]/4 changes.
gcc/testsuite/
	* g++.dg/cpp23/ext-floating1.C: New test.
	* g++.dg/cpp23/ext-floating2.C: New test.
	* g++.dg/cpp23/ext-floating3.C: New test.
	* g++.dg/cpp23/ext-floating4.C: New test.
	* g++.dg/cpp23/ext-floating5.C: New test.
	* g++.dg/cpp23/ext-floating6.C: New test.
	* g++.dg/cpp23/ext-floating7.C: New test.
	* g++.dg/cpp23/ext-floating8.C: New test.
	* g++.dg/cpp23/ext-floating9.C: New test.
	* g++.dg/cpp23/ext-floating10.C: New test.
	* g++.dg/cpp23/ext-floating.h: New file.
	* g++.target/i386/float16-1.C: Adjust expected diagnostics.
libcpp/
	* expr.cc (interpret_float_suffix): Allow {f,F}{16,32,64,128} and
	{f,F}{32,64,128}x suffixes for C++.
include/
	* demangle.h (enum demangle_component_type): Add
	DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.
	(struct demangle_component): Add u.s_extended_builtin member.
libiberty/
	* cp-demangle.c (d_dump): Handle
	DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.  Don't handle
	DEMANGLE_COMPONENT_FIXED_TYPE.
	(d_make_extended_builtin_type): New function.
	(cplus_demangle_builtin_types): Add _Float entry.
	(cplus_demangle_type): For DF demangle it as _Float<N> or
	_Float<N>x rather than fixed point which conflicts with it.
	(d_count_templates_scopes): Handle
	DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.  Just break; for
	DEMANGLE_COMPONENT_FIXED_TYPE.
	(d_find_pack): Handle DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.
	Don't handle DEMANGLE_COMPONENT_FIXED_TYPE.
	(d_print_comp_inner): Likewise.
	* cp-demangle.h (D_BUILTIN_TYPE_COUNT): Bump.
	* testsuite/demangle-expected: Replace _Z3xxxDFyuVb test
	with _Z3xxxDF16_DF32_DF64_DF128_CDF16_Vb.  Add
	_Z3xxxDF32xDF64xDF128xCDF32xVb test.
fixincludes/
	* inclhack.def (glibc_cxx_floatn_1, glibc_cxx_floatn_2,
	glibc_cxx_floatn_3): New fixes.
	* tests/base/bits/floatn.h: New file.
	* fixincl.x: Regenerated.

The function rebuild_location_adhoc_htab() was meant to reconstruct the
adhoc location hash map after restoring a line_maps instance from a
PCH. However, the function has never performed as intended because it
missed the last step of adding the data into the newly reconstructed hash
map. This patch fixes that.

It does not seem possible to construct a test case such that the current
incorrect behavior is observable as a compiler issue. It would be
observable, if it were possible for a precompiled header to contain an
adhoc location with a non-zero custom data pointer. But currently, such
data pointers are used only by the middle end to track inlining
information, and this happens later, too late to show up in a PCH.

I also noted that location_adhoc_data_update, which updates the hash map
pointers in a different scenario, was relying on undefined pointer
arithmetic behavior. I'm not aware of this having caused any issue in
practice, but in this patch I have also changed it to use defined pointer
operations instead.

libcpp/ChangeLog:

	* line-map.cc (location_adhoc_data_update): Remove reliance on
	undefined behavior.
	(get_combined_adhoc_loc): Likewise.
	(rebuild_location_adhoc_htab): Fix issue where the htab was not
	properly updated.