gcc/po/
	* gcc.pot: Regenerate.

libcpp/po/
	* cpplib.pot: Regenerate.

The logic in libcpp/Makefile.in listing diagnostic functions in a call
to xgettext was missing cpp_warning_at, cpp_pedwarning_at and
cpp_error_at, so resulting in some messages not being extracted for
translation; add those functions to those for which messages are
extracted.

Tested with "make cpplib.pot".

	* Makefile.in (po/$(PACKAGE).pot): Also handle cpp_warning_at,
	cpp_pedwarning_at and cpp_error_at.

As mentioned in the PR, in some cases we preprocess incorrectly when we
encounter an identifier which is defined as function-like macro, followed
by at least 2 CPP_PADDING tokens and then some other identifier.
On the following testcase, the problem is in the 3rd funlike_invocation_p,
the tokens are CPP_NAME Y, CPP_PADDING (the pfile->avoid_paste shared token),
CPP_PADDING (one created with padding_token, val.source is non-NULL and
val.source->flags & PREV_WHITE is non-zero) and then another CPP_NAME.
funlike_invocation_p remembers there was a padding token, but remembers the
first one because of its condition, then the next token is the CPP_NAME,
which is not CPP_OPEN_PAREN, so the CPP_NAME token is backed up, but as we
can't easily backup more tokens, it pushes into a new context the padding
token (the pfile->avoid_paste one).  The net effect is that when Y is not
defined as fun-like macro, we read Y, avoid_paste, padding_token, Y,
while if Y is fun-like macro, we read Y, avoid_paste, avoid_paste, Y
(the second avoid_paste is because that is how we handle end of a context).
Now, for stringify_arg that is unfortunately a significant difference,
which handles CPP_PADDING tokens with:
      if (token->type == CPP_PADDING)
        {
          if (source == NULL
              || (!(source->flags & PREV_WHITE)
                  && token->val.source == NULL))
            source = token->val.source;
          continue;
        }
and later on
      /* Leading white space?  */
      if (dest - 1 != BUFF_FRONT (pfile->u_buff))
        {
          if (source == NULL)
            source = token;
          if (source->flags & PREV_WHITE)
            *dest++ = ' ';
        }
      source = NULL;
(and c-ppoutput.cc has similar code).
So, when Y is not fun-like macro, ' ' is added because padding_token's
val.source->flags & PREV_WHITE is non-zero, while when it is fun-like
macro, we don't add ' ' in between, because source is NULL and so
used from the next token (CPP_NAME Y), which doesn't have PREV_WHITE set.

Now, the funlike_invocation_p condition
       if (padding == NULL
           || (!(padding->flags & PREV_WHITE) && token->val.source == NULL))
        padding = token;
looks very similar to that in stringify_arg/c-ppoutput.cc, so I assume
the intent was to prefer do the same thing and pick the right padding.
But there are significant differences.  Both stringify_arg and c-ppoutput.cc
don't remember the CPP_PADDING token, but its val.source instead, while
in funlike_invocation_p we want to remember the padding token that has the
significant information for stringify_arg/c-ppoutput.cc.
So, IMHO we want to overwrite padding if:
1) padding == NULL (remember that there was any padding at all)
2) padding->val.source == NULL (this matches the source == NULL
   case in stringify_arg)
3) !(padding->val.source->flags & PREV_WHITE) && token->val.source == NULL
   (this matches the !(source->flags & PREV_WHITE) && token->val.source == NULL
   case in stringify_arg)

2022-02-01  Jakub Jelinek  <jakub@redhat.com>

	PR preprocessor/104147
	* macro.cc (funlike_invocation_p): For padding prefer a token
	with val.source non-NULL especially if it has PREV_WHITE set
	on val.source->flags.  Add gcc_assert that CPP_PADDING tokens
	don't have PREV_WHITE set in flags.

	* c-c++-common/cpp/pr104147.c: New test.

The funlike_invocation_p macro never triggered, the other
asserts did on some tests, see below for a full list.
This seems to be caused by #pragma/_Pragma handling.
do_pragma does:
          pfile->directive_result.src_loc = pragma_token_virt_loc;
          pfile->directive_result.type = CPP_PRAGMA;
          pfile->directive_result.flags = pragma_token->flags;
          pfile->directive_result.val.pragma = p->u.ident;
when it sees a pragma, while start_directive does:
  pfile->directive_result.type = CPP_PADDING;
and so does _cpp_do__Pragma.
Now, for #pragma lex.cc will just ignore directive_result if
it has CPP_PADDING type:
              if (_cpp_handle_directive (pfile, result->flags & PREV_WHITE))
                {
                  if (pfile->directive_result.type == CPP_PADDING)
                    continue;
                  result = &pfile->directive_result;
                }
but destringize_and_run does not:
  if (pfile->directive_result.type == CPP_PRAGMA)
    {
...
    }
  else
    {
      count = 1;
      toks = XNEW (cpp_token);
      toks[0] = pfile->directive_result;
and from there it will copy type member of CPP_PADDING, but all the
other members from the last CPP_PRAGMA before it.
Small testcase for it with no option (at least no -fopenmp or -fopenmp-simd).
 #pragma GCC push_options
 #pragma GCC ignored "-Wformat"
 #pragma GCC pop_options
void
foo ()
{
  _Pragma ("omp simd")
  for (int i = 0; i < 64; i++)
    ;
}

Here is a patch that replaces those
      toks = XNEW (cpp_token);
      toks[0] = pfile->directive_result;
lines with
      toks = &pfile->avoid_paste;

2022-02-01  Jakub Jelinek  <jakub@redhat.com>

	* directives.cc (destringize_and_run): Push &pfile->avoid_paste
	instead of a copy of pfile->directive_result for the CPP_PADDING
	case.

Stephan Bergmann reported that our -Wbidi-chars breaks the build
of LibreOffice because we warn about UCNs even when their usage
is correct: LibreOffice constructs strings piecewise, as in:

  aText = u"\u202D" + aText;

and warning about that is overzealous.  Since no editor (AFAIK)
interprets UCNs to show them as Unicode characters, there's less
risk in misinterpreting them, and so perhaps we shouldn't warn
about them by default.  However, identifiers containing UCNs or
programs generating other programs could still cause confusion,
so I'm keeping the UCN checking.  To turn it on, you just need
to use -Wbidi-chars=unpaired,ucn or -Wbidi-chars=any,ucn.

The implementation is done by using the new EnumSet feature.

	PR preprocessor/104030

gcc/c-family/ChangeLog:

	* c.opt (Wbidi-chars): Mark as EnumSet.  Also accept =ucn.

gcc/ChangeLog:

	* doc/invoke.texi: Update documentation for -Wbidi-chars.

libcpp/ChangeLog:

	* include/cpplib.h (enum cpp_bidirectional_level): Add
	bidirectional_ucn.  Set values explicitly.
	* internal.h (cpp_reader): Adjust warn_bidi_p.
	* lex.cc (maybe_warn_bidi_on_close): Don't warn about UCNs
	unless UCN checking is on.
	(maybe_warn_bidi_on_char): Likewise.

gcc/testsuite/ChangeLog:

	* c-c++-common/Wbidi-chars-10.c: Turn on UCN checking.
	* c-c++-common/Wbidi-chars-11.c: Likewise.
	* c-c++-common/Wbidi-chars-14.c: Likewise.
	* c-c++-common/Wbidi-chars-16.c: Likewise.
	* c-c++-common/Wbidi-chars-17.c: Likewise.
	* c-c++-common/Wbidi-chars-4.c: Likewise.
	* c-c++-common/Wbidi-chars-5.c: Likewise.
	* c-c++-common/Wbidi-chars-6.c: Likewise.
	* c-c++-common/Wbidi-chars-7.c: Likewise.
	* c-c++-common/Wbidi-chars-8.c: Likewise.
	* c-c++-common/Wbidi-chars-9.c: Likewise.
	* c-c++-common/Wbidi-chars-ranges.c: Likewise.
	* c-c++-common/Wbidi-chars-18.c: New test.
	* c-c++-common/Wbidi-chars-19.c: New test.
	* c-c++-common/Wbidi-chars-20.c: New test.
	* c-c++-common/Wbidi-chars-21.c: New test.
	* c-c++-common/Wbidi-chars-22.c: New test.
	* c-c++-common/Wbidi-chars-23.c: New test.

As pointed out by pahole.

2022-01-18  Richard Biener  <rguenther@suse.de>

libcpp/
	* include/line-map.h (class line_maps): Re-arrange fields
	to minimize padding.
	(class rich_location): Likewise.
	* line-map.cc (rich_location::rich_location): Adjust.