When we read preprocessed source, we deal with a couple of special
location lines at the start of the file.  These provide information
about the original filename of the source and the current directory,
so we can process the source in the same manner.  When updating that
code, I had a somewhat philosophical question: Should the line table
contain evidence of the filename the user provided to the compiler?  I
figured to leave it there, as it did no harm.  But this defect shows
an issue.  It's in the line table and our (non optimizing) line table
serializer emits that filename.  Which means if one re-preprocesses
the original source to a differently-named intermediate file, the
resultant CMI is different.  Boo.  That's a difference that doesn't
matter, except the CRC matching then fails.  We should elide the
filename, so that one can preprocess to mktemp intermediate filenames
for whatever reason.

This patch takes the approach of expunging it from the line table --
so the line table will end up with exactly the same form.  That seems
a better bet than trying to fix up mismatching line tables in CMI
emission.

	PR c++/99072
	libcpp/
	* init.c (read_original_filename): Expunge all evidence of the
	original filename.
	gcc/testsuite/
	* g++.dg/modules/pr99072.H: New.

Integer literal suffixes for signed size ('z') and unsigned size
(some permutation od 'zu') are provided as a language addition.

gcc/c-family/ChangeLog:

	* c-cppbuiltin.c (c_cpp_builtins): Define __cpp_size_t_suffix.
	* c-lex.c (interpret_integer): Set node type for size literal.

libcpp/ChangeLog:

	* expr.c (interpret_int_suffix): Detect 'z' integer suffix.
	(cpp_classify_number): Compat warning for use of 'z' suffix.
	* include/cpplib.h (struct cpp_options): New flag.
	(enum cpp_warning_reason): New flag.
	(CPP_N_USERDEF): Comment C++0x -> C++11.
	(CPP_N_SIZE_T): New flag for cpp_classify_number.
	* init.c (cpp_set_lang): Initialize new flag.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/udlit-shadow-neg.C: Test for 'z' and 'zu' shadowing.
	* g++.dg/cpp23/feat-cxx2b.C: New test.
	* g++.dg/cpp23/size_t-literals.C: New test.
	* g++.dg/warn/Wsize_t-literals.C: New test.

Derived from the changes that added C++2a support in 2017.
r8-3237-g026a79f70cf33f836ea5275eda72d4870a3041e5

No C++23 features are added here.
Use of -std=c++23 sets __cplusplus to 202100L.

$ g++ -std=c++23 -dM -E -x c++ - < /dev/null | grep cplusplus
 #define __cplusplus 202100L

gcc/
	* doc/cpp.texi (__cplusplus): Document value for -std=c++23
	or -std=gnu++23.
	* doc/invoke.texi: Document -std=c++23 and -std=gnu++23.
	* dwarf2out.c (highest_c_language): Recognise C++20 and C++23.
	(gen_compile_unit_die): Recognise C++23.

gcc/c-family/
	* c-common.h (cxx_dialect): Add cxx23 as a dialect.
	* c.opt: Add options for -std=c++23, std=c++2b, -std=gnu++23
	and -std=gnu++2b
	* c-opts.c (set_std_cxx23): New.
	(c_common_handle_option): Set options when -std=c++23 is enabled.
	(c_common_post_options): Adjust comments.
	(set_std_cxx20): Likewise.

gcc/testsuite/
	* lib/target-supports.exp (check_effective_target_c++2a):
	Check for C++2a or C++23.
	(check_effective_target_c++20_down): New.
	(check_effective_target_c++23_only): New.
	(check_effective_target_c++23): New.
	* g++.dg/cpp23/cplusplus.C: New.

libcpp/
	* include/cpplib.h (c_lang): Add CXX23 and GNUCXX23.
	* init.c (lang_defaults): Add rows for CXX23 and GNUCXX23.
	(cpp_init_builtins): Set __cplusplus to 202100L for C++23.

It's past time to update this macro to the specified value for C++20.

libcpp/ChangeLog:

	* init.c (cpp_init_builtins): Update __cplusplus for C++20.

This adds the capability to locate the main file on the user or system
include paths.  That's extremely useful to users building header
units.  Searching has to be requiested (plain header-unit compilation
will not search).  Also, to make include_next work as expected when
building a header unit, we add a mechanism to retrofit a non-searched
source file as one on the include path.

	libcpp/
	* include/cpplib.h (enum cpp_main_search): New.
	(struct cpp_options): Add main_search field.
	(cpp_main_loc): Declare.
	(cpp_retrofit_as_include): Declare.
	* internal.h (struct cpp_reader): Add main_loc field.
	(_cpp_in_main_source_file): Not main if main is a header.
	* init.c (cpp_read_main_file): Use main_search option to locate
	main file.  Set main_loc
	* files.c (cpp_retrofit_as_include): New.

C++20 modules introduces a new kind of preprocessor directive -- a
module directive.  These are directives but without the leading '#'.
We have to detect them by sniffing the start of a logical line.  When
detected we replace the initial identifiers with unspellable tokens
and pass them through to the language parser the same way deferred
pragmas are.  There's a PRAGMA_EOL at the logical end of line too.

One additional complication is that we have to do header-name lexing
after the initial tokens, and that requires changes in the macro-aware
piece of the preprocessor.  The above sniffer sets a counter in the
lexer state, and that triggers at the appropriate point.  We then do
the same header-name lexing that occurs on a #include directive or
has_include pseudo-macro.  Except that the header name ends up in the
token stream.

A couple of token emitters need to deal with the new token possibility.

	gcc/c-family/
	* c-lex.c (c_lex_with_flags): CPP_HEADER_NAMEs can now be seen.
	libcpp/
	* include/cpplib.h (struct cpp_options): Add module_directives
	option.
	(NODE_MODULE): New node flag.
	(struct cpp_hashnode): Make rid-code a bitfield, increase bits in
	flags and swap with type field.
	* init.c (post_options): Create module-directive identifier nodes.
	* internal.h (struct lexer_state): Add directive_file_token &
	n_modules fields.  Add module node enumerator.
	* lex.c (cpp_maybe_module_directive): New.
	(_cpp_lex_token): Call it.
	(cpp_output_token): Add '"' around CPP_HEADER_NAME token.
	(do_peek_ident, do_peek_module): New.
	(cpp_directives_only): Detect module-directive lines.
	* macro.c (cpp_get_token_1): Deal with directive_file_token
	triggering.

C2x adds binary integer constants (approved at the last WG14 meeting,
though not yet added to the working draft in git).  Configure libcpp
to consider these a standard feature in C2x mode, with appropriate
updates to diagnostics including support for diagnosing them with
-std=c2x -Wc11-c2x-compat.

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

gcc/testsuite/
2020-11-13  Joseph Myers  <joseph@codesourcery.com>

	* gcc.dg/binary-constants-2.c, gcc.dg/binary-constants-3.c,
	gcc.dg/system-binary-constants-1.c: Update expected diagnostics.
	* gcc.dg/c11-binary-constants-1.c,
	gcc.dg/c11-binary-constants-2.c, gcc.dg/c2x-binary-constants-1.c,
	gcc.dg/c2x-binary-constants-2.c, gcc.dg/c2x-binary-constants-3.c:
	New tests.

libcpp/
2020-11-13  Joseph Myers  <joseph@codesourcery.com>

	* expr.c (cpp_classify_number): Update diagnostic for binary
	constants for C.  Also diagnose binary constants for
	-Wc11-c2x-compat.
	* init.c (lang_defaults): Enable binary constants for GNUC2X and
	STDC2X.

C2x adds the __has_c_attribute preprocessor operator, similar to C++
__has_cpp_attribute.

GCC implements __has_cpp_attribute as exactly equivalent to
__has_attribute.  (The documentation says they differ regarding the
values returned for standard attributes, but that's actually only a
matter of the particular nonzero value returned not being specified in
the documentation for __has_attribute; the implementation makes no
distinction between the two.)

I don't think having them exactly equivalent is actually correct,
either for __has_cpp_attribute or for __has_c_attribute.
Specifically, I think it is only correct for __has_cpp_attribute or
__has_c_attribute to return nonzero if the given attribute is
supported, with the particular pp-tokens passed to __has_cpp_attribute
or __has_c_attribute, with [[]] syntax, not if it's only accepted in
__attribute__ or with gnu:: added in [[]].  For example, they should
return nonzero for gnu::packed, but zero for plain packed, because
[[gnu::packed]] is accepted but [[packed]] is ignored as not a
standard attribute.

This patch implements that for __has_c_attribute, leaving any changes
to __has_cpp_attribute for the C++ maintainers.  A new
BT_HAS_STD_ATTRIBUTE is added for __has_c_attribute (which I think,
based on the above, would actually be correct to use for
__has_cpp_attribute as well).  The code in c_common_has_attribute that
deals with scopes has its C++ conditional removed; instead, whether
the language is C or C++ is used only to determine the numeric values
returned for standard attributes (and which standard attributes are
handled there at all).  A new argument is passed to
c_common_has_attribute to distinguish BT_HAS_STD_ATTRIBUTE from
BT_HAS_ATTRIBUTE, and that argument is used to stop attributes with no
scope specified from being accepted with __has_c_attribute unless they
are one of the known standard attributes and so handled specially.

Although the standard specify constants ending with 'L' as the values
for the standard attributes, there is no correctness issue with the
lack of code in GCC to add that 'L' to the expansion:
__has_c_attribute and __has_cpp_attribute are expanded in #if after
other macro expansion has occurred, with no semantics being specified
if they occur outside #if, so there is no way for a conforming program
to inspect the exact text of the expansion of those macros, only to
use the resulting pp-number in a #if expression, where long and int
have the same set of values.

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

gcc/
2020-11-12  Joseph Myers  <joseph@codesourcery.com>

	* doc/cpp.texi (__has_attribute): Document when scopes are allowed
	for C.
	(__has_c_attribute): New.

gcc/c-family/
2020-11-12  Joseph Myers  <joseph@codesourcery.com>

	* c-lex.c (c_common_has_attribute): Take argument std_syntax.
	Allow scope for C.  Handle standard attributes for C.  Do not
	accept unscoped attributes if std_syntax and not handled as
	standard attributes.
	* c-common.h (c_common_has_attribute): Update prototype.

gcc/testsuite/
2020-11-12  Joseph Myers  <joseph@codesourcery.com>

	* gcc.dg/c2x-has-c-attribute-1.c, gcc.dg/c2x-has-c-attribute-2.c,
	gcc.dg/c2x-has-c-attribute-3.c, gcc.dg/c2x-has-c-attribute-4.c:
	New tests.

libcpp/
2020-11-12  Joseph Myers  <joseph@codesourcery.com>

	* include/cpplib.h (struct cpp_callbacks): Add bool argument to
	has_attribute.
	(enum cpp_builtin_type): Add BT_HAS_STD_ATTRIBUTE.
	* init.c (builtin_array): Add __has_c_attribute.
	(cpp_init_special_builtins): Handle BT_HAS_STD_ATTRIBUTE.
	* macro.c (_cpp_builtin_macro_text): Handle BT_HAS_STD_ATTRIBUTE.
	Update call to has_attribute for BT_HAS_ATTRIBUTE.
	* traditional.c (fun_like_macro): Handle BT_HAS_STD_ATTRIBUTE.

Joseph pointed me at cb_get_source_date_epoch, which allows repeatable
builds and solves a FIXME I had on the modules branch.  Unfortunately
it's used exclusively to generate __DATE__ and __TIME__ values, which
fallback to using a time(2) call.  It'd be nicer if the preprocessor
made whatever time value it determined available to the rest of the
compiler.  So this patch adds a new cpp_get_date function, which
abstracts the call to the get_source_date_epoch hook, or uses time
directly.  The value is cached.  Thus the timestamp I end up putting
on CMI files matches __DATE__ and __TIME__ expansions.  That seems
worthwhile.

	libcpp/
	* include/cpplib.h (enum class CPP_time_kind): New.
	(cpp_get_date): Declare.
	* internal.h (struct cpp_reader): Replace source_date_epoch with
	time_stamp and time_stamp_kind.
	* init.c (cpp_create_reader): Initialize them.
	* macro.c (_cpp_builtin_macro_text): Use cpp_get_date.
	(cpp_get_date): Broken out from _cpp_builtin_macro_text and
	genericized.