[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

Kai Tietz <ktietz at gcc dot gnu.org> changed:

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

--- Comment #12 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-01-13 23:00:54 UTC ---
On inspecting this more closely, I agree with patriciak784.  The issue isn't
directly related to the fix of Richard for PR20239.

So I suggest patch for c-family/c-ppoutput.c as following:

Index: c-family/c-ppoutput.c
===================================================================
--- c-family/c-ppoutput.c       (revision 183106)
+++ c-family/c-ppoutput.c       (working copy)
@@ -86,7 +86,7 @@
 {
   /* A successful cpp_read_main_file guarantees that we can call
      cpp_scan_nooutput or cpp_get_token next.  */
-  if (flag_no_output)
+  if (flag_no_output && pfile->buffer)
     {
       /* Scan -included buffers, then the main file.  */
       while (pfile->buffer->prev)

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[patriciak784-gccmainling at yahoo dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

--- Comment #13 from patriciak784-gccmainling at yahoo dot de 2012-01-15 14:27:00 UTC ---
(In reply to comment #12)
> On inspecting this more closely, I agree with patriciak784.  The issue isn't
> directly related to the fix of Richard for PR20239.
> 
> So I suggest patch for c-family/c-ppoutput.c as following:
> 
> Index: c-family/c-ppoutput.c
> ===================================================================
> --- c-family/c-ppoutput.c       (revision 183106)
> +++ c-family/c-ppoutput.c       (working copy)
> @@ -86,7 +86,7 @@
>  {
>    /* A successful cpp_read_main_file guarantees that we can call
>       cpp_scan_nooutput or cpp_get_token next.  */
> -  if (flag_no_output)
> +  if (flag_no_output && pfile->buffer)
>      {
>        /* Scan -included buffers, then the main file.  */
>        while (pfile->buffer->prev)

I'd welcome if this patch was included in GCC.

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

--- Comment #14 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-06-27 14:03:13 UTC ---
Author: ktietz
Date: Wed Jun 27 14:03:08 2012
New Revision: 189016

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189016
Log:
        PR preprocessor/37215
        * c-ppoutput.c (preprocess_file): Check for nonempty buffer.

Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-ppoutput.c

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

--- Comment #15 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-06-27 15:06:21 UTC ---
Author: ktietz
Date: Wed Jun 27 15:06:16 2012
New Revision: 189019

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189019
Log:
        Merged from trunk
        PR preprocessor/37215
        * c-ppoutput.c (preprocess_file): Check for nonempty buffer.

Modified:
    branches/gcc-4_7-branch/gcc/c-family/ChangeLog
    branches/gcc-4_7-branch/gcc/c-family/c-ppoutput.c

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

Kai Tietz <ktietz at gcc dot gnu.org> changed:

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

--- Comment #16 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-06-27 15:10:19 UTC ---
I won't back-merge change to 4.6.x or earlier branches.
So I change bug to state resolved fixed.

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[patriciak784-gccmainling at yahoo dot de]

------- Comment #11 from patriciak784-gccmainling at yahoo dot de  2009-02-01 11:44 -------
I am sorry that I was a bit unclear - 4.0.0 @ 95634 works for PR20239 but
doesn't for this problem.
But the patch from PR20239 fixed both problems on 3.4.4, so both bugs are no
duplicates, sorry.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[patriciak784-gccmainling at yahoo dot de]

------- Comment #10 from patriciak784-gccmainling at yahoo dot de  2009-02-01 11:22 -------
(In reply to comment #6)

> read_original_filename lexes a token, which hits EOF, which

> causes the buffer to be popped.

> 

> This is sort of an odd scenario.

> Perhaps working around it in preprocess_file is best.

> 

Tom, I did investigate that problem a bit more with the compilers (see end of
comment for versioninfo).

All 4.x branches + trunk @ rev 143756 fail in preprocess_file but 3.4.6
doesn't.

The reason 3.4.6 does not fail is the patch applied to 3.4 branch by Richard
Guenther because of PR20239(perhaps we should even mark this bug as a duplicate
and reopen 20239).
The patch didn't make it into 4.0 because the code there had already been
changed from
  if (CPP_OPTION (pfile, preprocessed))
    {
      read_original_filename (pfile);
+      if (!pfile->map)
+       return NULL;
      fname = pfile->map->to_file;
    }
to
  if (CPP_OPTION (pfile, preprocessed))
    {
      read_original_filename (pfile);
      fname = pfile->line_table->maps[pfile->line_table->used-1].to_file;
    }
(see function cpp_read_main_file in gcc/cppinit.c libcpp/init.c respectively)
The two lines beginning with + are Richard's fix.

pfile->map seems to get NULL if there is only whitespace in the file or nothing
at all. Therefore 3.4.4 segfaulted on pfile->map->to_file.
By returning NULL, the function calling cpp_read_main_file,
c_common_post_options will increment errorcount
(=global_dc->diagnostic_count[DK_ERROR])
which leads to the code calling preprocess_file to be skipped and therefore
there is no segfault on 3.4.6.
On the 4.x branches cpp_read_main_file will not return NULL in that case and
preprocess_file will be executed and segfault.

I just wonder why in PR20239, 4.0.0 is said to work. I don't know which
revision Andrew Pinski used but rev 95634 fails for me and I fail to build the
3.3.3 release which is supposed to succeed either.
Perhaps the code leading to the error was introduced around that time and 4.0
branch and trunk but I don't actually think so. If 3.3.3 worked, I assume the
bug was introduced in the 3.4 development cycle.

After all it is now up to you Tom or another maintainer to decide if to apply
my piece of code or create something else (perhaps something in
cpp_read_main_file like Richard did about 4 years ago). I have no objections
against either possibility.
Perhaps someone could verify what I did and update known to fail and known to
work to 3.4.6 | 4.0.4 4.1.3 4.2.5 4.3.4 4.4.0.

And one last thing: this is a regression from 3.4.6.

==========================gcc versioninfo =====================================
I compiled gcc 3.4,4.0,4.1,4.2,4.3 and 4.4 from svn rev 143756
-v outputs:
Reading specs from
/media/OSS/final/gcc-3.4/bin/../lib/gcc/x86_64-unknown-linux-gnu/3.4.6/specs
Configured with: ../../gcc3.4/configure --prefix=/gcc/final/gcc-3.4
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib
Thread model: posix
gcc version 3.4.6
===============================================================================
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.0/configure --prefix=/gcc/final/gcc-4.0
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib
Thread model: posix
gcc version 4.0.4
===============================================================================
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.1/configure --prefix=/gcc/final/gcc-4.1
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib
Thread model: posix
gcc version 4.1.3 20080704 (prerelease)
===============================================================================
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.2/configure --prefix=/gcc/final/gcc-4.2-143756
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib --disable-bootstrap
Thread model: posix
gcc version 4.2.5 20090129 (prerelease)
===============================================================================
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.3/configure --prefix=/gcc/final/gcc-4.3-143756
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib --disable-bootstrap
Thread model: posix
gcc version 4.3.4 20090129 (prerelease) (GCC) 
===============================================================================
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.4/configure --prefix=/gcc/final/gcc-4.4-143756
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib --disable-bootstrap
Thread model: posix
gcc version 4.4.0 20090129 (experimental) (GCC)
===============================================================================
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc-4_0-branch/configure
--prefix=/gcc/final/gcc-4.0-95634 --disable-multilib --enable-languages=c,c++
--with-gnu-ld --with-gnu-as --disable-nls --with-system-zlib
--disable-bootstrap
Thread model: posix
gcc version 4.0.0 20050227 (prerelease) <- rev 95634


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[patriciak784-gccmainling at yahoo dot de]

------- Comment #9 from patriciak784-gccmainling at yahoo dot de  2009-01-05 08:43 -------
I don't think it's good to apply the workaround mainly because 3.4.5 works for
me on mingw and the code that triggers the error hasn't changed since its
initial commit which was more than 5 years ago.

I assume that in 3.4.5, every empty input file gets an empty buffer instead of
none which is what happens at the moment in 4.3 or something like that...
So if my assumption is true, the code that does that buffer handling would need
to copy the old behaviour...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[patriciak784-gccmainling at yahoo dot de]

------- Comment #8 from patriciak784-gccmainling at yahoo dot de  2009-01-04 20:53 -------
(In reply to comment #7)
> does indeed fix or work around (with gcc 4.3 branch revision somewhere around
> rev143000) the original problem ('gcc -E -dM -fpreprocessed - < /dev/null') on
> mingw32 and x86_64 debian gnu linux.

The only thing I can really tell is that there is no segfault any more and
there is not output all all - the same thing as if I replace /dev/null with an
empty file.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[patriciak784-gccmainling at yahoo dot de]

------- Comment #7 from patriciak784-gccmainling at yahoo dot de  2009-01-04 20:26 -------
(In reply to comment #6)
> read_original_filename lexes a token, which hits EOF, which
> causes the buffer to be popped.
> 
> This is sort of an odd scenario.
> Perhaps working around it in preprocess_file is best.
> 
Perhaps.
I'm glad someone looked at this again.

I just verified again that changing the lines to
#  if (flag_no_output)
#    {
#      /* Scan -included buffers, then the main file.  */
#      while(pfile->buffer)
#        cpp_scan_nooutput (pfile);
#    }
does indeed fix or work around (with gcc 4.3 branch revision somewhere around
rev143000) the original problem ('gcc -E -dM -fpreprocessed - < /dev/null') on
mingw32 and x86_64 debian gnu linux.

But my own problem (PR37331) is quite strange. When I run gcc 4.3 in the
debugger it works, when I run it outside it fails with SIGSEV in cc1 which is
just totally strange. But the really strange thing is that the official mingw
3.4.5r3 does always work for me. I'll have to try again on another PC.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[tromey at gcc dot gnu dot org]

------- Comment #6 from tromey at gcc dot gnu dot org  2009-01-02 17:04 -------
read_original_filename lexes a token, which hits EOF, which
causes the buffer to be popped.

This is sort of an odd scenario.
Perhaps working around it in preprocess_file is best.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[patriciak784-gccmainling at yahoo dot de]

------- Comment #5 from patriciak784-gccmainling at yahoo dot de  2008-09-07 14:41 -------
Sorry, my "patch" doesn't always fix the problem. It is just strange. Sometimes
it works, sometimes not...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[patriciak784-gccmainling at yahoo dot de]

------- Comment #4 from patriciak784-gccmainling at yahoo dot de  2008-09-04 16:38 -------
Now I know why gcc complains about a misformed pch file nul.gch!
Checking if a file named NUL plus any extension exists, will always return that
it exists because I did this on windows! open will not open a file on the disk
but the NUL device which is the same as /dev/null on *nix.
And of course nul.gch is no valid pch!

So this warning is a windows specific "bug" but I don't think it is necessary
to provide a workaround in gcc as long as this doesn't break anything which is
the case at least for me.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[patriciak784-gccmainling at yahoo dot de]

------- Comment #3 from patriciak784-gccmainling at yahoo dot de  2008-09-04 13:35 -------
I did examine both problems a bit further.
If I understand correctly what is happening, there is the object parse_in which
is, during program flow, passed to preprocess_file as argument pfile.
An object of type cpp_reader seems to have several buffers which are organized
as a stack. The topmost buffer worked is saved in ->buffer.
And now preprocess_file gets the cpp_reader object and as 'flag_no_output' is
true (I don't know why...) the function tries to pop all buffers from the
buffer stack and by popping them does some processing on them (by doing a loop
as long as there is a previous buffer pfile->buffer->prev and then doing
another call to cpp_scan_nooutput for the last buffer).
All files seem to have at least one buffer but processing "/dev/null"
temporarily creates a buffer but unallocates it beacause EOF is reached before
calling preprocess_file. 
And this function does not check if there _is_ a buffer pfile->buffer != NULL
and therefore both commands fail.
At the moment the important lines (file gcc/c-ppoutput.c lines 71..77) look
like this:
  if (flag_no_output)
    {
      /* Scan -included buffers, then the main file.  */
      while (pfile->buffer->prev)
        cpp_scan_nooutput (pfile);
      cpp_scan_nooutput (pfile);
    }
I did try
  if (flag_no_output)
    {
      if(pfile->buffer)
     {
      /* Scan -included buffers, then the main file.  */
      while (pfile->buffer->prev)
        cpp_scan_nooutput (pfile);
      cpp_scan_nooutput (pfile);
     }
    }
And it does indeed work - no segfaults any more! :->
This part can perhaps even be optimized a bit:
  if (flag_no_output)
    {
      /* Scan -included buffers, then the main file.  */
      while(pfile->buffer)
        cpp_scan_nooutput (pfile);
    }
I didn't test that one yet but I suppose it works.
I suppose someone should run the testsuite and post the results...

And one more thing:
running 'gcc -c out.o -x c /dev/null' now prints:
cc1: warning: nul.gch: too short to be a PCH file (nul.gch probably because on
windows /dev/null is internally converted to the system file NUL which does the
same this as /dev/null on *nix)
Do you think this output is the right thing to do? Or is that a bug, too?
At least out.o is an empty object file.
and running 'gcc -E -dM -fpreprocessed - < /dev/null' doesn't print anything.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-09-03 21:14 -------
*** Bug 37331 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |patriciak784-gccmainling at
                   |                            |yahoo dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-08-24 22:12 -------
Confirmed, I don't know if this is a regression or not.
Program received signal SIGSEGV, Segmentation fault.
0x1006f204 in preprocess_file (pfile=0x10a03728) at
/home/apinski/src/local/gcc/gcc/c-ppoutput.c:88
88            while (pfile->buffer->prev)
(gdb) p pfile
$1 = (cpp_reader *) 0x10a03728
(gdb) p pfile->buffer
$2 = (cpp_buffer *) 0x0


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
  GCC build triplet|x86_64-unknown-linux-gnu    |
   GCC host triplet|x86_64-unknown-linux-gnu    |
 GCC target triplet|x86_64-unknown-linux-gnu    |
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|0000-00-00 00:00:00         |2008-08-24 22:12:20
               date|                            |
            Version|3.1                         |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215