[Bug c++/105732] New: [REGRESSION] internal compiler error: unspellable token PADDING

[Bug c++/105732] New: [REGRESSION] internal compiler error: unspellable token PADDING

[linux_dr at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

            Bug ID: 105732
           Summary: [REGRESSION] internal compiler error: unspellable
                    token PADDING
           Product: gcc
           Version: 11.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: linux_dr at yahoo dot com
  Target Milestone: ---

Created attachment 53033
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53033&action=edit
Source file, with no includes, exhibiting the issue.

Regression appeared between 11.2.0 and 11.3.0.

viewable online with "Compiler Explorer”: https://godbolt.org/z/bsenoqdjv

g++ (Compiler-Explorer-Build-gcc--binutils-2.36.1) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

===What we need===

Please include all of the following items, the first three of which can be
obtained from the output of gcc -v:

* the exact version of GCC:
   + g++ 11.3.0

* the system type:
   + x86_64-linux-gnu

* the options given when GCC was configured/built:
   + From debug output:

COLLECT_GCC=/opt/compiler-explorer/gcc-11.3.0/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-11.3.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,go,d --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc--binutils-2.36.1
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.3.0 (Compiler-Explorer-Build-gcc--binutils-2.36.1)
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-S' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
'-dumpdir' '/app/'

* the complete command line that triggers the bug:
   + From debug output:

/opt/compiler-explorer/gcc-11.3.0/bin/../libexec/gcc/x86_64-linux-gnu/11.3.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-11.3.0/bin/../lib/gcc/x86_64-linux-gnu/11.3.0/
-D_GNU_SOURCE <source> -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext
.cpp -masm=intel -mtune=generic -march=x86-64 -g -version
-fdiagnostics-color=always -o /app/output.s

* the compiler output (error messages, warnings, etc.):
    + (attached)

* the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug
report for the GNAT front end, a complete set of source files (see below).
   + As the bug appears to be in the preprocessor, I think the single source
file may be sufficient: (attached)
      (It should also be included in the link above)

[Bug c++/105732] [REGRESSION] internal compiler error: unspellable token PADDING

[linux_dr at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #1 from Loren Osborn <linux_dr at yahoo dot com> ---
Created attachment 53034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53034&action=edit
Complete Compiler output

Only allowed to attach one file to initial bug report

[Bug c++/105732] [REGRESSION] internal compiler error: unspellable token PADDING

[linux_dr at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #2 from Loren Osborn <linux_dr at yahoo dot com> ---
Just noting that this is my **THIRD** time submitting this bug. @jwakely had to
come bail me out twice after spam assassin did it's thing. You may want to:

1) Turn down the sensitivity on spam assassin
2) Review the spam assassin logs to see what other bug reports may have been
kicked out without a determined user following up.

[Bug c++/105732] [REGRESSION] internal compiler error: unspellable token PADDING

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

Reduced as much as I could:

#define _VA_FEATURE_DETECT__3RD_ARG(_placeholder_1, _placeholder_2, value, ...)
value

#      define _VA_FEATURE_OPT_DISAPPEARS 1
#      define _VA_FEATURE_OPT_DISAPPEARS__VA_OPT__(_placeholder) 0
#      define _VA_FEATURE_OPT_DETECT_UNEXPANDED(...)
_VA_FEATURE_OPT_DISAPPEARS##__VA_OPT__(foo)
#      define _VA_FEATURE_OPT_DETECT_VERIFY_2_ARGS_TEST_ZERO(_placeholder_1,
_placeholder_2) \
        _VA_FEATURE_OPT_DETECT_UNEXPANDED()
#      define _VA_FEATURE_OPT_DETECT_1_OR_2_ARGS(_placeholder, ...) \
        _VA_FEATURE_DETECT__3RD_ARG(__VA_ARGS__, \
                                   
_VA_FEATURE_OPT_DETECT_VERIFY_2_ARGS_TEST_ZERO, \
                                    0)
#      define _VA_FEATURE_OPT_DETECT_1_ARG(...) \
        _VA_FEATURE_OPT_DETECT_1_OR_2_ARGS(bar, __VA_OPT__(, ))(__VA_OPT__(, ))
#      define _VA_FEATURE_OPT_DETECT_SUPPORTED _VA_FEATURE_OPT_DETECT_1_ARG(?)

#      if _VA_FEATURE_OPT_DETECT_SUPPORTED
#      endif

[Bug preprocessor/105732] [11/12/13 Regression] internal compiler error: unspellable token PADDING

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|                            |2022-05-25
             Status|UNCONFIRMED                 |NEW
   Target Milestone|---                         |11.4
      Known to fail|                            |11.3.0, 12.1.0, 13.0
            Summary|[REGRESSION] internal       |[11/12/13 Regression]
                   |compiler error: unspellable |internal compiler error:
                   |token PADDING               |unspellable token PADDING
      Known to work|                            |10.3.0, 11.2.0, 9.4.0
     Ever confirmed|0                           |1
          Component|c++                         |preprocessor

[Bug preprocessor/105732] [11/12/13 Regression] internal compiler error: unspellable token PADDING

[linux_dr at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #4 from Loren Osborn <linux_dr at yahoo dot com> ---
(*Comment lost in submit collision*)

Just a couple last notes:

1) Go here first: https://godbolt.org/z/bsenoqdjv. (Easy to reproduce bug in a
simple link.)
2) I filed this bug against 11.3.0, as that is when the regression appeared,
but Compiler Explorer seems to show that this is still a current bug on trunk

Regarding Andrew Pinski's shortening of the code sample, I mostly left the
comments there for context. (I actually found this bug by accident: This code
was never intended to run against GCC >= 8. Due to a bug in my code, I found
this bug.) This is chopped down from a ~460 line header file already.

I hope that helps!

[Bug preprocessor/105732] [11/12/13 Regression] internal compiler error: unspellable token PADDING

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Started with r12-6155-g5545d1edcbdb17

[Bug preprocessor/105732] [11/12/13 Regression] internal compiler error: unspellable token PADDING

[linux_dr at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #6 from Loren Osborn <linux_dr at yahoo dot com> ---
This is unlikely to be helpful or relevant, but just in case, this is the
source of the original code: https://developer.blender.org/D14947

[Bug preprocessor/105732] [11/12/13 Regression] internal compiler error: unspellable token PADDING

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Loren Osborn from comment #4)
> 2) I filed this bug against 11.3.0, as that is when the regression appeared,
> but Compiler Explorer seems to show that this is still a current bug on trunk

Right, this is why there are "known to work" and "know to fail" fields that I
filled out to reflect where the regression showed up and they will be updated
when the bug gets fixed. The reported against version is good to have if we
could not reproduce it right away.

[Bug preprocessor/105732] [9/10/11/12/13 Regression] internal compiler error: unspellable token PADDING

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.4                        |9.5
      Known to fail|                            |10.3.1, 9.4.1
            Summary|[11/12/13 Regression]       |[9/10/11/12/13 Regression]
                   |internal compiler error:    |internal compiler error:
                   |unspellable token PADDING   |unspellable token PADDING
           Severity|normal                      |blocker

[Bug preprocessor/105732] [9/10/11/12/13 Regression] internal compiler error: unspellable token PADDING

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
/* PR preprocessor/105732 */

#define m1(p1, p2, p3) p3
#define m2(p1, ...) 1##__VA_OPT__(foo)
#define M(...) m1(1, 2, m2)
#if M(,)(,)
#endif

[Bug preprocessor/105732] [9/10/11/12/13 Regression] internal compiler error: unspellable token PADDING

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
With a slightly modified testcase:
#define m1(p1, p2, p3) p3
#define m2(p1, ...) 1 __VA_OPT__()
#define M(...) m1(1, 2, m2)
#if M(,)(,)
#endif
it started to ICE already with r8-6791-g60887f8c2df851 aka PR83708 fix.

The r12-6155-g5545d1edcbdb17 change just turns that into the same tokens as
before, while previously it wasn't.  As __VA_OPT__() or __VA_OPT__(foo) in both
cases expands to nothing, 1##nothing is still 1 and the avoid_paste token is
added afterwards to make sure token after __VA_OPT__() isn't emitted right
after it without whitespace.

It isn't immediately clear to me what should be eating the padding token so
that
cpp_parse_expr doesn't see it.

Or is this a bug in cpp_parse_expr?
I mean, other callers of cpp_get_token_with_location like e.g. in
c_lex_with_flags handle CPP_PADDING by calling cpp_get_token_with_location
again.
Similarly scan_translation_unit when doing -E, token_streamer::stream just
remembers there was padding and goes on (and takes that into account whether
whitespace should be emitted or not).

[Bug preprocessor/105732] [9/10/11/12/13 Regression] internal compiler error: unspellable token PADDING

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53038
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53038&action=edit
gcc13-pr105732.patch

Untested fix.

[Bug preprocessor/105732] [9/10/11/12/13 Regression] internal compiler error: unspellable token PADDING

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug preprocessor/105732] [10/11/12/13 Regression] internal compiler error: unspellable token PADDING

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4
            Summary|[9/10/11/12/13 Regression]  |[10/11/12/13 Regression]
                   |internal compiler error:    |internal compiler error:
                   |unspellable token PADDING   |unspellable token PADDING

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
The offending change was reverted on the GCC-9 branch.

[Bug preprocessor/105732] [10/11/12/13 Regression] internal compiler error: unspellable token PADDING

[herrtimson at yahoo dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #12 from tt_1 <herrtimson at yahoo dot de> ---
With the revert included in the release tarball, it seems that gcc-9.5.0 is
'known to work' then?

[Bug preprocessor/105732] [10/11/12/13 Regression] internal compiler error: unspellable token PADDING

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Not entirely. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732#c8 will work
there, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732#c9 does not.

[Bug preprocessor/105732] [10/11/12/13 Regression] internal compiler error: unspellable token PADDING

[linux_dr at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #14 from Loren Osborn <linux_dr at yahoo dot com> ---
(In reply to Jakub Jelinek from comment #13)
> Not entirely. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732#c8 will
> work there, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732#c9 does not.

If this is the case, shouldn’t these be split into at least two test cases?

[Bug preprocessor/105732] [10/11/12/13 Regression] internal compiler error: unspellable token PADDING

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:58a40e76ebadce78639644cd3d56e42b68336927

commit r13-819-g58a40e76ebadce78639644cd3d56e42b68336927
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sun May 29 21:57:51 2022 +0200

    libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732]

    The first part of the following testcase (m1-m3 macros and its use)
    regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows,
    the problem isn't new, we can emit a CPP_PADDING token to avoid it from
    being adjacent to whatever comes after the __VA_OPT__ (in this case there
    is nothing afterwards, true).

    In most cases these CPP_PADDING tokens don't matter, all other
    callers of cpp_get_token_with_location either ignore CPP_PADDING tokens
    completely (e.g. c_lex_with_flags) or they just remember them and
    take them into account when printing stuff whether there should be
    added whitespace or not (scan_translation_unit + token_streamer::stream).
    So, I think we should just ignore CPP_PADDING tokens the same way in
    _cpp_parse_expr.

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

            PR preprocessor/105732
            * expr.cc (_cpp_parse_expr): Handle CPP_PADDING by just another
            token.

            * c-c++-common/cpp/va-opt-10.c: New test.

[Bug preprocessor/105732] [10/11/12/13 Regression] internal compiler error: unspellable token PADDING

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:8f32de15e469673935618fc1a998dcafddb0bbf4

commit r12-8436-g8f32de15e469673935618fc1a998dcafddb0bbf4
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sun May 29 21:57:51 2022 +0200

    libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732]

    The first part of the following testcase (m1-m3 macros and its use)
    regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows,
    the problem isn't new, we can emit a CPP_PADDING token to avoid it from
    being adjacent to whatever comes after the __VA_OPT__ (in this case there
    is nothing afterwards, true).

    In most cases these CPP_PADDING tokens don't matter, all other
    callers of cpp_get_token_with_location either ignore CPP_PADDING tokens
    completely (e.g. c_lex_with_flags) or they just remember them and
    take them into account when printing stuff whether there should be
    added whitespace or not (scan_translation_unit + token_streamer::stream).
    So, I think we should just ignore CPP_PADDING tokens the same way in
    _cpp_parse_expr.

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

            PR preprocessor/105732
            * expr.cc (_cpp_parse_expr): Handle CPP_PADDING by just another
            token.

            * c-c++-common/cpp/va-opt-10.c: New test.

    (cherry picked from commit 58a40e76ebadce78639644cd3d56e42b68336927)

[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11/12/13 Regression]    |[10/11 Regression] internal
                   |internal compiler error:    |compiler error: unspellable
                   |unspellable token PADDING   |token PADDING

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 12.2 and 13+ so far.

[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING

[linux_dr at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #18 from Loren Osborn <linux_dr at yahoo dot com> ---
It appears this fix has already been merged into trunk. Is there a reason this
isn't marked "Resolved"? Is that usually not updated until the next release?

[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It hasn't been fixed on 11 and 10 branches yet, that is why it is kept open but
12/13 has been removed from the Summary.

[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING

[linux_dr at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #20 from Loren Osborn <linux_dr at yahoo dot com> ---
great... thank you for the update.

[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:49e320ac0792672e2137ca47215fd7f935302895

commit r11-10072-g49e320ac0792672e2137ca47215fd7f935302895
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sun May 29 21:57:51 2022 +0200

    libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732]

    The first part of the following testcase (m1-m3 macros and its use)
    regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows,
    the problem isn't new, we can emit a CPP_PADDING token to avoid it from
    being adjacent to whatever comes after the __VA_OPT__ (in this case there
    is nothing afterwards, true).

    In most cases these CPP_PADDING tokens don't matter, all other
    callers of cpp_get_token_with_location either ignore CPP_PADDING tokens
    completely (e.g. c_lex_with_flags) or they just remember them and
    take them into account when printing stuff whether there should be
    added whitespace or not (scan_translation_unit + token_streamer::stream).
    So, I think we should just ignore CPP_PADDING tokens the same way in
    _cpp_parse_expr.

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

            PR preprocessor/105732
            * expr.c (_cpp_parse_expr): Handle CPP_PADDING by just another
            token.

            * c-c++-common/cpp/va-opt-10.c: New test.

    (cherry picked from commit 58a40e76ebadce78639644cd3d56e42b68336927)

[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

--- Comment #22 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:b2f5dc82400fe04511b85caa8c80677f81eee415

commit r10-10846-gb2f5dc82400fe04511b85caa8c80677f81eee415
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sun May 29 21:57:51 2022 +0200

    libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732]

    The first part of the following testcase (m1-m3 macros and its use)
    regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows,
    the problem isn't new, we can emit a CPP_PADDING token to avoid it from
    being adjacent to whatever comes after the __VA_OPT__ (in this case there
    is nothing afterwards, true).

    In most cases these CPP_PADDING tokens don't matter, all other
    callers of cpp_get_token_with_location either ignore CPP_PADDING tokens
    completely (e.g. c_lex_with_flags) or they just remember them and
    take them into account when printing stuff whether there should be
    added whitespace or not (scan_translation_unit + token_streamer::stream).
    So, I think we should just ignore CPP_PADDING tokens the same way in
    _cpp_parse_expr.

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

            PR preprocessor/105732
            * expr.c (_cpp_parse_expr): Handle CPP_PADDING by just another
            token.

            * c-c++-common/cpp/va-opt-10.c: New test.

    (cherry picked from commit 58a40e76ebadce78639644cd3d56e42b68336927)

[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed even for 10.4 and 11.4.

[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jens.gustedt at inria dot fr

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
*** Bug 109284 has been marked as a duplicate of this bug. ***