As can be seen in the testcase, we don't diagnose #include/#include_next
of a non-existent header if __has_include/__has_include_next is done for
that header first.
The problem is that we normally error the first time some header is not
found, but in the _cpp_FFK_HAS_INCLUDE case obviously don't want to diagnose
it, just expand it to 0.  And libcpp caches both successful includes and
unsuccessful ones.

The following patch fixes that by remembering that we haven't diagnosed
error when using __has_include* on it, and diagnosing it when using the
cache entry in normal mode the first time.

I think _cpp_FFK_NORMAL is the only mode in which we normally diagnose
errors, for _cpp_FFK_PRE_INCLUDE that open_file_failed isn't reached
and for _cpp_FFK_FAKE neither.

2023-06-15  Jakub Jelinek  <jakub@redhat.com>

	PR preprocessor/80753
libcpp/
	* files.cc (struct _cpp_file): Add deferred_error bitfield.
	(_cpp_find_file): When finding a file in cache with deferred_error
	set in _cpp_FFK_NORMAL mode, call open_file_failed and clear the flag.
	Set deferred_error in _cpp_FFK_HAS_INCLUDE mode if open_file_failed
	hasn't been called.
gcc/testsuite/
	* c-c++-common/missing-header-5.c: New test.

	* ru.po: Update.

This reverts commit e7ce7c49.

From 0821df518b264e754d698d399f98be1a62945e32 Mon Sep 17 00:00:00 2001
From: Longjun Luo <luolongjuna@gmail.com>
Date: Thu, 12 Jan 2023 23:59:54 +0800
Subject: [PATCH] libcpp: suppress builtin macro redefined warnings for
 __LINE__

As implied in
gcc.gnu.org/legacy-ml/gcc-patches/2008-09/msg00076.html,
gcc provides -Wno-builtin-macro-redefined to suppress warning when
redefining builtin macro. However, at that time, there was no
scenario for __LINE__ macro.

But, when we try to build a live-patch, we compare sections by using
-ffunction-sections. Some same functions are considered changed because
of __LINE__ macro.

At present, to detect such a changed caused by __LINE__ macro, we
have to analyse code and maintain a function list. For example,
in kpatch, check this commit
github.com/dynup/kpatch/commit/0e1b95edeafa36edb7bcf11da6d1c00f76d7e03d.

So, in this scenario, when we try to compared sections, it would
be better to support suppress builtin macro redefined warnings for
__LINE__ macro.

libcpp:
	* init.cc (builtin_array): Do not always warn for a redefinition
	of __LINE__.

gcc/testsuite

	* gcc.dg/builtin-redefine.c: Test for redefintion warnings
	for __LINE__.
	* gcc.dg/builtin-redefine-1.c: New test.

PR analyzer/109098 notes that the SARIF spec mandates that .sarif
files are UTF-8 encoded, but -fdiagnostics-format=sarif-file naively
assumes that the source files are UTF-8 encoded when quoting source
artefacts in the .sarif output, which can lead to us writing out
.sarif files with non-UTF-8 bytes in them (which break my reporting
scripts).

The root cause is that sarif_builder::maybe_make_artifact_content_object
was using maybe_read_file to load the file content as bytes, and
assuming they were UTF-8 encoded.

This patch reworks both overloads of this function (one used for the
whole file, the other for snippets of quoted lines) so that they go
through input.cc's file cache, which attempts to decode the input files
according to the input charset, and then encode as UTF-8.  They also
check that the result actually is UTF-8, for cases where the input
charset is missing, or incorrectly specified, and omit the quoted
source for such awkward cases.

Doing so fixes all of the cases I've encountered.

The patch adds a new:
  { dg-final { verify-sarif-file } }
directive to all SARIF test cases in the test suite, which verifies
that the output is UTF-8 encoded, and is valid JSON.  In particular
it verifies that when we complain about encoding problems, the .sarif
report we emit is itself correctly encoded.

gcc/ChangeLog:
	PR analyzer/109098
	* diagnostic-format-sarif.cc (read_until_eof): Delete.
	(maybe_read_file): Delete.
	(sarif_builder::maybe_make_artifact_content_object): Use
	get_source_file_content rather than maybe_read_file.
	Reject it if it's not valid UTF-8.
	* input.cc (file_cache_slot::get_full_file_content): New.
	(get_source_file_content): New.
	(selftest::check_cpp_valid_utf8_p): New.
	(selftest::test_cpp_valid_utf8_p): New.
	(selftest::input_cc_tests): Call selftest::test_cpp_valid_utf8_p.
	* input.h (get_source_file_content): New prototype.

gcc/testsuite/ChangeLog:
	PR analyzer/109098
	* c-c++-common/diagnostic-format-sarif-file-1.c: Add
	verify-sarif-file directive.
	* c-c++-common/diagnostic-format-sarif-file-2.c: Likewise.
	* c-c++-common/diagnostic-format-sarif-file-3.c: Likewise.
	* c-c++-common/diagnostic-format-sarif-file-4.c: Likewise.
	* c-c++-common/diagnostic-format-sarif-file-Wbidi-chars.c: New
	test case, adapted from Wbidi-chars-1.c.
	* c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-1.c:
	New test case.
	* c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-2.c:
	New test case.
	* c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-3.c:
	New test case, adapted from cpp/Winvalid-utf8-1.c.
	* c-c++-common/diagnostic-format-sarif-file-valid-CP850.c: New
	test case, adapted from gcc.dg/diagnostic-input-charset-1.c.
	* gcc.dg/plugin/crash-test-ice-sarif.c: Add verify-sarif-file
	directive.
	* gcc.dg/plugin/crash-test-write-though-null-sarif.c: Likewise.
	* gcc.dg/plugin/diagnostic-test-paths-5.c: Likewise.
	* lib/scansarif.exp (verify-sarif-file): New procedure.
	* lib/verify-sarif-file.py: New support script.

libcpp/ChangeLog:
	PR analyzer/109098
	* charset.cc (cpp_valid_utf8_p): New function.
	* include/cpplib.h (cpp_valid_utf8_p): New prototype.

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

I've noticed I forgot to update copyright years when updating from
Unicode 15.0.0 (and makeucnid.cc had it hopelessly obsolete).

2023-03-16  Jakub Jelinek  <jakub@redhat.com>

	* makeucnid.cc (write_copyright): Update Unicode copyright years
	up to 2022.
	* makeuname2c.cc (write_copyright): Likewise.
	* ucnid.h: Regenerated.
	* uname2c.h: Regenerated.

get__Pragma_string() in directives.cc is responsible for lexing the parens
and the string argument from a _Pragma("...") operator. This function does
not handle the case when the closing paren is not on the same line as the
string; in that case, libcpp will by default reuse the token buffer it
previously used for the string, so that the string token returned by
get__Pragma_string() may be corrupted, as shown in the testcase. Fix using
the existing keep_tokens mechanism that temporarily disables the reuse of
token buffers.

libcpp/ChangeLog:

	PR preprocessor/67046
	* directives.cc (_cpp_do__Pragma): Increment pfile->keep_tokens to
	ensure the returned string token is valid.

gcc/testsuite/ChangeLog:

	PR preprocessor/67046
	* c-c++-common/cpp/pr67046.c: New test.

Updates cpp_wcwidth() to Unicode 15, following the procedure in
contrib/unicode/README mechanically without incident.

contrib/ChangeLog:

	* unicode/DerivedCoreProperties.txt: Update to Unicode 15.
	* unicode/DerivedNormalizationProps.txt: Likewise.
	* unicode/EastAsianWidth.txt: Likwise.
	* unicode/PropList.txt: Likewise.
	* unicode/README: Likewise.
	* unicode/UnicodeData.txt: Likewise.

libcpp/ChangeLog:

	* generated_cpp_wcwidth.h: Regenerated for Unicode 15.

	* 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.