[Bug pch/115312] New: [14/15 Regression] ICE when including a PCH via compiler option -include

[Bug pch/115312] New: [14/15 Regression] ICE when including a PCH via compiler option -include

[gcc at mailinator dot com]

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

            Bug ID: 115312
           Summary: [14/15 Regression] ICE when including a PCH via
                    compiler option -include
           Product: gcc
           Version: 14.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: pch
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc at mailinator dot com
  Target Milestone: ---
              Host: x86_64-w64-mingw32
            Target: x86_64-w64-mingw32
             Build: x86_64-w64-mingw32

An internal compiler error is triggered in GCC 14.1.0 when including a
precompiled header via compiler option -include. A testcase is provided below:

```
touch test.cpp
touch test.h

g++ test.h
g++ -include test.h -c test.cpp -save-temps
test.cpp:1: internal compiler error: in c_init_preprocess, at cp/parser.cc:790
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.
```

This issue shows up on (i686|x86_64)-w64-mingw32 platforms. GCC 14.1.0 releases
from MSYS2 and WinLibs projects are affected.

I have done some tests with prebuilt GCC 14 pre-releases from WinLibs project.

- Last working GCC 14 pre-release is from snapshot gcc-14-20231119.
- First GCC 14 pre-release with this issue is from snapshot gcc-14-20231217.

[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include

[lhyatt at gcc dot gnu.org]

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

Lewis Hyatt <lhyatt at gcc dot gnu.org> changed:

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

--- Comment #1 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
Hmm that is odd. It works fine on x86-64/Linux so I think this is something
target-specific with PCH? If this assert is firing:

void
c_init_preprocess ()
{
  gcc_assert (!the_parser);
...

It means that the_parser was not NULL after reading in the PCH. But it should
be, because the_parser is explicitly set to NULL prior to writing the PCH (at
the end of c_parse_file() in cp/parse.cc) and so that's what it should get set
to after reading the PCH back in. Are you able to confirm whether the_parser
stored in the PCH is indeed NULL, maybe? I don't have anywhere to test this
platform myself at the moment. Thanks...

That assert could be simply removed too, but it does seem worth understanding
how it can trigger here...

[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.2

[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include

[brechtsanders at users dot sourceforge.net]

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

Brecht Sanders <brechtsanders at users dot sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brechtsanders at users dot sourcef
                   |                            |orge.net

--- Comment #2 from Brecht Sanders <brechtsanders at users dot sourceforge.net> ---
I have made a native Windows MinGW-w64 build where the lines "gcc_assert
(!the_parser);" were commented out in file gcc/cp/parser.cc and got
confirmation this successfully works around the issue.

See: https://github.com/brechtsanders/winlibs_mingw/issues/199

[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include

[lhyatt at gcc dot gnu.org]

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

--- Comment #3 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
(In reply to Brecht Sanders from comment #2)
> I have made a native Windows MinGW-w64 build where the lines "gcc_assert
> (!the_parser);" were commented out in file gcc/cp/parser.cc and got
> confirmation this successfully works around the issue.

Thanks! Do you mind please confirming, are you building it with the following
downstream patch in place (which is not part of GCC itself as of now):
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0021-PR14940-Allow-a-PCH-to-be-mapped-to-a-different-addr.patch
? If so, it would be interesting if possible to confirm whether the assert
still triggers without that patch.

[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include

[brechtsanders at users dot sourceforge.net]

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

--- Comment #4 from Brecht Sanders <brechtsanders at users dot sourceforge.net> ---
No, that patch wasn't added for my build, see my build recipe here:
https://github.com/brechtsanders/winlibs_recipes/blob/main/recipes/gcc.winlib

[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include

[lhyatt at gcc dot gnu.org]

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

--- Comment #5 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
(In reply to Brecht Sanders from comment #4)
> No, that patch wasn't added for my build, see my build recipe here:
> https://github.com/brechtsanders/winlibs_recipes/blob/main/recipes/gcc.winlib

Thanks, this script is useful. FWIW I think the patch is there, line 778?
Unless I am missing something.

I see you also commented out the assert in your recipe. I am still not sure if
that is just masking some deeper issue, but I am getting close to being able to
reproduce it myself and will let you know.

[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include

[brechtsanders at users dot sourceforge.net]

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

--- Comment #6 from Brecht Sanders <brechtsanders at users dot sourceforge.net> ---
You're right. Sorry I missed that.

[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include since r14-5836

[lhyatt at gcc dot gnu.org]

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

Lewis Hyatt <lhyatt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-06-17
            Summary|[14/15 Regression] ICE when |[14/15 Regression] ICE when
                   |including a PCH via         |including a PCH via
                   |compiler option -include    |compiler option -include
                   |                            |since r14-5836

--- Comment #7 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
OK I see now. For the case of a PCH combined with -include it is a regression
in GCC 14 caused by r14-5836. I think any platform that does not make use of
the stdc-predef.h preinclude will be affected (including MinGW). 

The assert added in r14-5836 should not be failing, but it is failing due to an
oversight in r14-2893. This was a new feature for GCC 14 that made #pragma work
during preprocessing, which required the creation of a parser object in
preprocess-only mode.

I will test this patch that should fix it:

=====

diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index faaf9ee6350..a09a0518c52 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -1296,8 +1296,8 @@ c_common_init (void)

   if (flag_preprocess_only)
     {
-      c_finish_options ();
       c_init_preprocess ();
+      c_finish_options ();
       preprocess_file (parse_in);
       return false;
     }

=====

The problem is that c_finish_options() will also include the first
command-line- specified include file. On glibc platforms, this is always the
stdc-predef.h preinclude and then things work. In the absence of a preinclude,
it will include the first file requested with -include. If that file triggers a
PCH load, then we hit the code path introduced in r14-5836; after the PCH is
loaded, we reinitialize the parser. But in this case we have not called
c_init_preprocess() yet, so when we do call it afterward, the parser already
exists and so the assert fails. 

The above patch should make things right, I am testing it now and it should get
into GCC 14.2. You could add it to the list of MinGW-specific patches for
WinLibs and MSYS2 in the meantime too. It's preferable to commenting out the
assert, although that workaround probably does work fine at the moment as well.